当您有需要性能调整的查询或存储过程时，您首先尝试的是什么？
这是我总是向向我询问优化问题的人提供的方便实用的清单。
我们主要使用 Sybase，但大多数建议都适用。
例如，SQL Server 附带了许多性能监控/调整位，但如果您没有类似的东西（也许即使您有），那么我会考虑以下...
99%的问题我见过是由放引起的连接中的表太多。解决此问题的方法是执行一半的联接（使用某些表）并将结果缓存在临时表中。然后在该临时表上执行其余的查询连接。
查询优化清单
- Run UPDATE STATISTICS on the underlying tables
- Delete records from underlying tables (possibly archive the deleted records)
- 重建索引
- 重建表（bcp 数据输出/输入）
- 转储/重新加载数据库（剧烈，但可能会修复损坏）
- 建立新的、更合适的索引
- 运行 DBCC 查看数据库是否可能损坏
- Locks / Deadlocks
- Ensure no other processes running in database
- 您使用的是行级锁定还是页级锁定？
- 在开始查询之前以独占方式锁定表
- 检查所有进程是否以相同的顺序访问表
- Are indices being used appropriately?
- 仅当两个表达式的数据类型完全相同时，联接才会使用索引
- 仅当索引上的第一个字段在查询中匹配时才会使用索引
- Are clustered indices used where appropriate?
- 范围数据
- value1 和 value2 之间的 WHERE 字段
- Small Joins are Nice Joins
- 默认情况下，优化器一次只会考虑表 4。
- 这意味着在连接超过 4 个表时，它很有可能选择非最佳查询计划
- Break up the Join
- 可以解除连接吗？
- 将外键预选到临时表中
- 执行一半的连接并将结果放入临时表中
- Are you using the right kind of temporary table?
-
#temp表的性能可能比@table大量变量（数千行）。
- Maintain Summary Tables
- 在基础表上使用触发器进行构建
- 每天/每小时/等等构建。
- 构建临时的
- 增量构建或拆卸/重建
- 使用 SET SHOWPLAN ON 查看查询计划是什么
- 使用 SET STATISTICS IO ON 查看实际发生的情况
- 使用编译指示强制建立索引：(index: myindex)
- 使用 SET FORCEPLAN ON 强制表顺序
- Parameter Sniffing:
- 将存储过程分成 2 个
- 从 proc1 调用 proc2
- 如果 @parameter 已被 proc1 更改，则允许优化器在 proc2 中选择索引
- 你能改进你的硬件吗？
- 你几点跑步？还有更安静的时候吗？
- Replication Server（或其他不间断进程）是否正在运行？可以暂停一下吗？运行它例如。每小时？
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
