简介

　　对于写出实现功能的SQL语句和既能实现功能又能保证性能的SQL语句的差别是巨大的。很多时候开发人员仅仅是把精力放在实现所需的功能上，而忽略了其所写代码的性能和对SQL Server实例所产生的影响（也就是IO，CPU，内存方面的消耗）.这甚至有可能使整个SQL Server实例跪了。本文旨在提供一些简单的步骤来帮助你优化SQL语句。

　　市面上已经有很多关于如何优化SQL Server性能的书籍和白皮书。所以本文并不打算达到那种深度和广度，而仅仅是为开发人员提供一个快速检测的列表来找到SQL语句中导致瓶颈产生的部分。

　　在开始解决性能问题之前，合适的诊断工具是必须的。除去众所周知的SSMS和SQL Profiler，SQL Server 2008还带有众多DMV来提供关键信息。本篇文章中，我将使用SSMS和一些DMV来找到SQL的瓶颈

　　那么，我们从哪开始

　　我的第一步是查看执行计划。这一步既可以通过SMSS也可以通过SQL Profiler实现，为了简便起见，我将在SMSS中获取执行计划。

　　1） 检查你是否忽略掉了某些表的连接的条件，从而导致了笛卡尔积（Cross）连接（Join）。比如，在生产系统中有两个表，每个表中有1000行数据。这其中绝大多数数据并不需要返回，如果你在这两个表上应用了Cross Join，返回的结果将会是100万行的结果集！返回如此数量的数据包括将所有数据从物理存储介质中读取出来，因而占用了IO。然后这些数据将会被导入内存，也就是SQL Server的缓冲区。这会将缓冲区内的其它页Flush出去。

　　2）查看你是否忽略了某些Where子句，缺少Where子句会导致返回额外不需要的行。这产生的影响和步骤一所产生的影响是一样的。

　　3）查看统计信息是否是自动创建和自动更新的，你可以在数据库的属性里看到这些选项

　　在默认条件下创建一个新数据库，Auto Create Statistics和Auto Update Statistics选项是开启的，统计信息是用于帮助查询优化器生成最佳执行计划的。这份白皮书对于解释统计信息的重要性以及对于执行计划的作用解释的非常到位。上面那些设置可以通过右键数据库，选择属性，在“选项”中找到。

　　4）检查统计信息是否已经过期，虽然统计信息是自动创建的，但是更新统计信息从而反映出数据的变化也同样重要。在一个大表中，有时候虽然Auto Update Statistics 选项已经开始，但统计信息依然无法反映出数据的分布情况。默认情况下，统计信息的更新是基于抽取表中的随机信息作为样本产生的。如果数据是按顺序存储的，那么很有可能数据样本并没有反映出表中的数据情况。因此，推荐在频繁更新的表中，统计信息使用Full Scan选项来定期更新。这种更新可以放到数据库闲时来做。

　　DBCC SHOW_STATISTICS命令可以用于查看上次统计信息的更新时间，行数以及样本行数.在这个例子中，我们可以看到Person.Address表上的AK_Address_rowguid索引的有关信息：

　　下面是输出结果，请注意Updated,Rows,Rows Sampled这三个列