SQL查询优化

查询优化

完全通过系统级服务器性能优化（如内存大小、文件系统类型、处理器的数目及类型等）解决性能问题可能很诱人。但经验表明大多数性能问题不能用这种方法解决。必须通过这些方法解决性能问题：分析应用程序以及应用程序提交给数据库的查询和更新，并分析这些查询和更新如何与数据库架构交互。

持续时间意外地长的查询和更新可能由下列原因引起：

• 网络通讯速度慢。
  
  
• 服务器计算机的内存不足或 Microsoft® SQL Server™ 2000 可用的内存不足。
  
  
• 缺少有用的统计数据。
  
  
• 统计数据过期。
  
  
• 缺少有用的索引。
  
  
• 缺少有用的数据条带化。

当查询或更新花费的时间比预期的长时，使用下面的检查清单提高性能。

说明  建议在与技术支持提供商联系之前先参考该检查清单。

1. 性能问题与查询以外的组件是否有关？例如，问题是否为网络性能慢？是否有任何其它可能引起或间接导致性能下降的组件？可以使用 Windows NT 性能监视器监视与 SQL Server 相关和与 SQL Server 不相关的组件性能。有关更多信息，请参见使用系统监视器进行监视。
   
   
2. 如果性能问题与查询相关，涉及哪个查询或哪组查询？使用 SQL 事件探查器帮助识别慢速查询。有关更多信息，请参见使用 SQL 事件探查器进行监视。

   通过使用 SET 语句启用 SHOWPLAN、STATISTICS IO、STATISTICS TIME 和 STATISTICS PROFILE 选项，可以确定数据库查询性能。

   • SHOWPLAN 描述 SQL Server 查询优化器选择的数据检索方法。有关更多信息，请参见 SET SHOWPLAN_ALL。
     
     
   • STATISTICS IO 报告与语句内引用的每个表的扫描数、逻辑读取数（在高速缓存中访问的页数）和物理读取数（访问磁盘的次数）有关的信息。有关更多信息，请参见 SET STATISTICS IO。
     
     
   • STATISTICS TIME 显示分析、编译和执行查询所需的时间（以毫秒为单位）。有关更多信息，请参见 SET STATISTICS TIME。
     
     
   • STATISTICS PROFILE 显示每个查询执行后的结果集，代表查询执行的配置文件。有关更多信息，请参见 SET STATISTICS PROFILE。

   在 SQL 查询分析器中，还可以打开 graphical execution plan 选项查看关于 SQL Server 如何检索数据的图形表示。

   由这些工具收集的信息使您得以确定 SQL Server 查询优化器正在如何执行查询以及正在使用哪些索引。利用这些信息，可以确定通过重写查询、更改表上的索引或修改数据库设计等方法能否提高性能。有关更多信息，请参见分析查询。

3. 是否已经用有用的统计数据优化查询？

   SQL Server 自动在索引列上创建对列内的值分布情况的统计。也可以使用 SQL 查询分析器或 CREATE STATISTICS 语句在非索引列上手动创建统计；或者如果将 auto create statistics 数据库选项设置为 true，则自动在非索引列上创建统计。查询处理器可以利用这些统计确定最佳的查询评估策略。在联接操作所涉及的非索引列上维护附加的统计信息可以提高查询性能。有关更多信息，请参见统计信息。

   使用 SQL 事件探查器或 SQL 查询分析器内的图形执行计划来监视查询，以确定查询是否有足够的统计信息。有关更多信息，请参见错误和警告事件分类。

4. 查询统计信息是否为最新？统计信息是否自动更新？

   SQL Server 自动在索引列上创建并更新查询统计（只要没有禁用自动查询统计更新特性）。另外，可以使用 SQL 查询分析器或 UPDATE STATISTICS 语句在非索引列上手工更新统计；或者如果 auto update statistics 数据库选项设置为 true，则自动在非索引列上更新统计。最新的统计不取决于日期或时间数据。如果尚未进行 UPDATE 操作，则查询统计信息仍是最新的。

   如果没有将统计设置为自动更新，则应设置为自动更新。有关更多信息，请参见统计信息。

5. 是否有合适的索引？添加一个或多个索引是否会提高查询性能？有关更多信息，请参见索引优化建议。
   
   
6. 是否有任何数据热点或索引热点？如果有，考虑使用磁盘条带化。有关更多信息，请参见使用文件组放置数据和 RAID。
   
   
7. 是否为查询优化器提供了优化复杂查询的最有利条件？有关更多信息，请参见查询优化建议。

转载自：
http://www.cnblogs.com/niuniu502/archive/2006/07/26/460269.html