我有一些查询导致我们的实时环境超时。(>30 秒)
如果我运行分析器并获取正在运行的确切 SQL 并从 Management Studio 运行它,那么它们第一次运行需要很长时间,然后每次运行下降到几百毫秒。
这显然是 SQL 缓存数据并将其全部存储在内存中。
我确信可以对 SQL 进行优化,使其运行得更快。
我的问题是,当我第二次运行这些查询时,数据已经被缓存并且速度很快,我该如何“修复”这些查询?
我有一些查询导致我们的实时环境超时。(>30 秒)
如果我运行分析器并获取正在运行的确切 SQL 并从 Management Studio 运行它,那么它们第一次运行需要很长时间,然后每次运行下降到几百毫秒。
这显然是 SQL 缓存数据并将其全部存储在内存中。
我确信可以对 SQL 进行优化,使其运行得更快。
我的问题是,当我第二次运行这些查询时,数据已经被缓存并且速度很快,我该如何“修复”这些查询?
我是否可以建议您检查导致性能不佳问题的查询的执行计划。
您需要在执行计划中确定哪些步骤成本最高以及原因。例如,可能是您的查询正在执行表扫描,或者正在使用不适当的索引。
RedGate 网站上有一本非常详细的免费电子书,专门用于了解执行计划的内容。
https://www.red-gate.com/Dynamic/Downloads/DownloadForm.aspx?download=ebook1
您可能会发现有一个特定的执行计划希望用于您的查询。您可以使用查询提示强制 SQL Server 中的查询使用哪个执行计划。然而,这是一个相当先进的概念,应谨慎使用。有关详细信息,请参阅以下 Microsoft 白皮书。
http://www.microsoft.com/technet/prodtechnol/sql/2005/frcqupln.mspx
我也不建议您清除生产环境中的过程缓存,因为这将不利于平台上当前未遇到性能问题的所有其他查询的性能。
例如,如果您正在执行一个存储过程,您可以使用 WITH RECOMPILE 命令确保为每次执行该过程计算一个新的执行计划。
对于整体性能调优信息,Brent Ozar 的博客上有一些优秀的资源。
http://www.brentozar.com/sql-server-performance-tuning/
希望这可以帮助。干杯。
根据http://morten.lyhr.dk/2007/10/how-to-clear-sql-server-query-cache.html,您可以运行以下命令来清除缓存:
DBCC DROPCLEANBUFFERS
DBCC FREEPROCCACHE
编辑:我检查了我拥有的 SQL Server 文档,这对于 SQL Server 2000 来说至少是正确的。
使用可以使用
DBCC DROPCLEANBUFFERS
DBCC FREEPROCCACHE
但仅在您的开发环境中使用它,同时调整查询以部署到实时服务器。
我认为人们正朝着错误的方向逃跑。如果我明白了,您希望性能一直都很好吗?他们在第二次(以及随后的执行)中运行速度不快并且第一次运行速度很慢吗?
上面的 DBCC 命令会清除缓存,导致性能更差。
我认为,您想要的是启动泵并缓存数据。您可以通过一些执行查询并将数据加载到内存中的启动过程来做到这一点。
内存是一种有限资源,因此您可能无法将所有数据加载到内存中,但您可以找到平衡点。布伦特在上面有一些很好的参考资料,可以帮助您了解您可以在这里做什么。
查询优化是一个很大的主题,您的问题没有单一的答案。做什么的线索都在查询计划中,无论结果是否被缓存,查询计划都应该是相同的。
寻找常见的东西,例如表扫描、在您期望它们被使用时未使用的索引等。最终您可能不得不重新审视您的数据模型,并可能实施非规范化策略。
来自 MSDN:
“使用DBCC DROPCLEANBUFFERS使用冷缓冲区缓存测试查询,而无需关闭并重新启动服务器。”