最喜欢的性能调优技巧

这是我经常给问我有关优化问题的人的便捷清单。 我们主要使用Sybase，但是大多数建议将全面适用。

例如，SQL Server附带了许多性能监视/调整位，但是如果您没有这样的功能（甚至可能没有），那么我会考虑以下事项...

我看到的问题中有99％是由于在联接中放置太多表引起的。解决此问题的方法是进行一半的连接（使用某些表），并将结果缓存在临时表中。然后在该临时表上进行其余查询的联接。

查询优化清单 在基础表上运行UPDATE STATISTICS 许多系统将其作为计划的每周工作运行 从基础表中删除记录（可能存档已删除的记录） 考虑每天或每周一次自动执行此操作。 重建索引 重建表（bcp数据输出/输入） 转储/重新加载数据库（严重，但可能会修复损坏） 建立更合适的新索引 运行DBCC以查看数据库中是否可能损坏 锁/死锁 确保没有其他进程在数据库中运行 特别是DBCC 您是否在使用行级或页面级锁定？ 在开始查询之前以独占方式锁定表 检查所有进程是否以相同顺序访问表 是否正确使用了索引？ 如果两个表达式的数据类型完全相同，则联接将仅使用索引 仅当索引中的第一个字段在查询中匹配时才使用索引 是否在适当的地方使用聚集索引？ 范围数据 值1和值2之间的WHERE字段 小联接就是好联接 默认情况下，优化程序一次只考虑表4。 这意味着在联接超过4个表时，很有可能选择非最佳查询计划 分手加入 你能分手的加入？ 将外键预选到临时表中 做一半的连接并将结果放在临时表中 您使用的是正确的临时表吗？ #temp表的性能可能比@table大容量（数千行）的变量好得多。 维护汇总表 在基础表上使用触发器进行构建 每天/每小时/等等构建 临时构建 逐步构建或拆卸/重建 使用SET SHOWPLAN ON查看查询计划是什么 看看SET STATS IO ON实际发生了什么 使用编译指示强制索引：（索引：myindex） 使用SET FORCEPLAN ON强制执行表顺序 参数嗅探： 将存储过程分为2 从proc1调用proc2 如果@parameter已被proc1更改，则允许优化程序在proc2中选择索引 您可以改善硬件吗？ 你什么时候跑步？有安静的时间吗？ Replication Server（或其他不间断进程）是否正在运行？你可以暂停吗？运行它例如。每小时？