在大多数SQLServer工作环境中，尤其是在OLTP环境中，当数据库的事务日志性能出现瓶颈时，往往需要更多的时间来完成事务。这时候，很多人将原因归咎于I/O子系统，理由是它无法支持工作负载产生的大量事务日志，但实际情况可能并非如此。事务日志写等待时间对于事务日志，写操作的等待时间可以通过sys.dm_id_virtual_file_stats和系统中的事件writelogwaiting来监控。如果写入延迟高于您对I/O子系统的预期，则I/O子系统无法支持它。这是一般假设，但并不意味着您需要升级I/O子系统。在很多系统中，你会发现产生了相当比例的冗余日志记录。如果能够减少这些不必要的日志记录，写入磁盘的事务日志的数量就会相应减少，相应地转化为写入等待时间的减少，从而事务完成的时间也会减少。冗余日志记录的产生主要有两个原因：未使用的非聚集索引的增加索引碎片未使用的索引每当向表中插入一条记录时，它也会被添加到表上定义的每个索引中非聚集索引插入一条记录（注意过滤后的索引可能是个例外），这意味着产生了冗余的日志记录；删除表中的记录也是如此，相应的非聚簇索引中的记录也必须被删除，数据更新时，非聚簇索引中的记录也会以同样的方式被修改。这些操作对于维护每个非聚簇索引和相关表之间的正确关系（真实反映）是必要的，但是如果查询计划中不一定使用非聚簇索引，那么为维护它们而生成的操作和日志记录也将是多余的成本。随着非聚簇索引分片的增长，需要定期维护，维护也会产生更多的日志记录，完全没有必要。未使用的索引可能是在表上误创建的，或者是根据SQLServer缺失索引的DMV推荐创建的，或者是数据库的优化顾问创建的，也可能是业务变更导致的，之前使用的索引不再使用。无论如何，应该清除这些未使用的索引以减少负载。首先，确定哪些索引没有被使用。您可以通过DMVsys.dm_db_index_usage_stats查看它们。索引碎片在很多人的印象中，索引碎片会导致读取更多的数据页。其实索引碎片也会造成日志记录冗余，原因就是碎片的原因。碎片是由分页现象造成的。简单的解释就是当插入一条记录，空间不足时，分页。这个过程是这样的：一个新的索引被分配和格式化一半的记录从完整的页面移动到新的页面新的页面链接到索引结构，新的记录被插入到页面中记录产生更多的日志记录。减少额外成本的第一步是清除未使用的索引，目的是防止它们产生页分裂，所以要找出那些碎片化的索引，第二步决定使用哪种碎片整理方法是分析索引以确定碎片.您可以使用系统函数sys.dm_db_index_physical_stats检测特定索引、表或索引视图的所有索引、数据库中的所有索引或所有数据库中的所有索引中的碎片。对于分区索引，sys.dm_db_index_physical_stats还提供每个分区的碎片信息。SQLServer2005中计算碎片的算法比SQLServer2000中的算法更精确。因此，Fragmentation值显得更高。例如，在SQLServer2000中，如果第11页和第13页在同一范围内但第12页不是，则表不被视为碎片化。但是访问这两个页面需要两次物理I/O操作，因此在SQLServer2005中该表被计为碎片。使用索引填充因子重建或重组索引，为后续插入的记录保留索引中的一些空余空间，从而减少页分裂的发生，从而减少额外日志记录的产生。（请参考另一篇文章：找到那些不用的数据库索引）当然，天下没有免费的午餐，任何对一方有利的事情都可能对另一方有害。使用填充因子时，页面密度会降低。如果页面密度太低，也会导致一些性能问题。当然，如果太高，会造成分页，所以这是一个需要权衡的问题。有关详细信息，请参阅您的环境，例如OLTP或OLAP。总结减少事务日志写入等待时间并不总是需要升级您的I/O子系统。在数据库中使用简单的索引分析可以显着减少大量事务日志记录的产生，这也减少了写入等待时间。时间。当然，这只是影响事务日志性能的一方面。只有对事务日志的机制有了更深入的了解，你才会发现事务日志更多方面的性能。作者简介姜传华，长期从事数据库的教学、设计、开发和应用管理，拥有20多年的IT工作经验，对关系数据库和SQL原理有深刻的理解服务器架构。同时，他也活跃于微软各大论坛网站。我们一直在努力坚持原创……请不要二话不说就拿走。我原创，你原创，我们的内容世界会更精彩！
