我知道这是一个广泛的问题，但我继承了几个表现不佳的人，需要对他们进行严格的优化。我想知道优化所涉及的最常见步骤是什么。那么，当你面对同样的情况时，你们中的一些人会采取什么步骤？
相关问题：
What generic techniques can be applied to optimize SQL queries?
答案 0 :(得分：14)
答案 1 :(得分：7)
在SQL Server中，您可以查看查询分析器或Management Studio中的查询计划。这将告诉您在每批语句中花费的大部分时间。您需要查找以下内容：
其他一些一般提示：
最后，我强烈建议您创建一组负载测试（使用Visual Studio 2008测试版），您可以使用它来模拟应用程序在处理大量请求时的行为。某些SQL性能瓶颈仅在这些情况下表现出来，并且能够重现它们使得修复更加容易。
答案 2 :(得分：3)
索引可能是一个很好的起点...
使用 SQL Server 索引调整向导可以打破低挂果。
答案 3 :(得分：2)
我不确定其他数据库，但对于SQL Server，我建议执行计划。它非常清楚（尽管有很多垂直和水平滚动，除非你有400英寸显示器！）显示你的查询的哪些步骤正在吸引时间。
如果你有一个步骤需要一个疯狂的80％，那么可能会添加一个索引，然后在调整索引后，重新运行执行计划以找到你的下一个最大步骤。
经过几次调整后，您可能会发现确实没有其他步骤可以脱颖而出，即每个步骤都是1-2％。如果是这种情况，那么您可能需要查看是否有一种方法可以减少查询中包含的数据量，这些400万封闭销售订单是否需要包含在“活动销售订单”查询中？不，所以排除那些使用STATUS ='C'......或类似的东西。
您将从执行计划中看到的另一项改进是书签查找，基本上它在索引中找到匹配项，但SQL Server必须快速浏览表以查找所需的记录。此操作有时可能需要比首先扫描表所需的时间更长，如果是这样，您真的需要该索引吗？
使用索引，尤其是SQL Server 2005，您应该查看INCLUDE子句，这基本上允许您在索引中创建一个列，而不是真正在索引中，因此，如果查询所需的所有数据都在您的索引或是一个包含的列，然后SQL Server甚至不必查看表，这是一个很大的性能提升。
答案 4 :(得分：2)
您可以通过以下几种方法来优化查询效果。
确保您拥有最少的数据。确保只选择所需的列。将字段大小减小到最小。
考虑对数据库进行反规范化以减少连接
避免循环（即获取游标），坚持设置操作。
将查询实现为存储过程，因为这是预编译的，并且执行速度更快。
确保您已设置正确的索引。如果您的数据库主要用于搜索，那么请考虑更多索引。
使用执行计划查看处理是如何完成的。您想要避免的是桌面扫描，因为这样做很昂贵。
确保将“自动统计”设置为“开启”。 SQL需要这个来帮助决定最佳执行。有关更多信息，请参阅Mike Gunderloy的精彩帖子。 Basics of Statistics in SQL Server 2005
确保您的索引没有碎片Reducing SQL Server Index Fragmentation
确保您的表格没有碎片。 How to Detect Table Fragmentation in SQL Server 2000 and 2005
答案 5 :(得分：1)
查看进行查询的表上的索引。参与where子句的特定字段可能需要索引。还要查看查询中连接中使用的字段（如果存在连接）。如果索引已存在，请查看索引的类型。
失败（因为使用锁定提示存在负面影响）请查看锁定提示并明确命名要在连接中使用的索引。如果你遇到很多死锁事务，那么使用NOLOCKS会更加明显。
尽管罗马和安迪S首先提到了这一点。
答案 6 :(得分：1)
执行计划是一个很好的开始，可以帮助您找出需要解决的查询部分。
一旦你弄清楚了哪里，是时候解决方法和原因了。看看您尝试执行的查询类型。避免循环，因为它们很慢。不惜一切代价避免使用游标，因为它们很慢。尽可能坚持基于设置的查询。
如果使用连接，有很多方法可以提供有关要使用的连接类型的SQL提示。但请注意，虽然一个提示可能会加快您的查询速度，但根据数据和参数的不同，下次可能会使查询速度减慢10倍。
最后，确保您的数据库编入索引。一个好的起点是where子句中包含的任何字段可能都应该包含索引。