第二章 风驰电掣——有效缩短SQL优化过程

参考《收获，不止SQL优化》作者: 梁敬彬 / 梁敬弘

如何缩短SQL优化的过程

注意：此处探讨的是缩短SQL优化的过程，而不是缩短SQL的执行时间

1、首先，需要清楚，SQL优化的过程是否有效缩短，是用什么指标来衡量？

从我们接到某个模块运行很慢的问题开始，从收到问题—>找出原因（获取信息+具体分析）—>着手优化—>验证通过，将这整个过程所花的时间作为一个衡量指标，我们需要考虑的是如何将这个指标值降低。

2、其次，我们来拆解这个指标

**【收到问题】**这一步，看似没必要讨论，但其实如果一开始收到问题时就附上全面而具体的信息，将会对优化过程有很大帮助。
以下问题（可做调整）可以整理成一份标准文档，报告人提交优化需求时，提前了解清楚这些问题并填写提交。（仅做参考和前期的判断，方便合理地安排任务和调整检查步骤，有些问题后面还是要亲自确认过。）

**【找出原因】**这一步，我们要做具体分析，肯定要了解一些信息。特别是无法远程访问的生产问题，开发测试环境无法复现，那这些信息的来回搜集，将会非常耗时。
所以获取信息这一步，最好能提前写好脚本并部署，需要时一键获取。
而具体分析这一步，主要取决于优化人员对SQL的了解和经验，暂不做分析。

ASH报告：可以看到那些长时间等待事件跟哪些SQL相关，可以看看，是否有我们需要优化的SQL，如果有的话，就可以看到具体原因（比如日志切换频繁可能是提交频繁，可以考虑批量提交；如果有并行度等待，查看对应的表上是否设置了并行度属性；等等）。

AWRSQ报告：可以分析某段时间内具体SQL的执行时间，频率，是否有不同的执行计划，对应的执行计划是什么，对SQL优化也有很帮助。

**【着手优化】**这一步，一般我们找出原因后，就可着手优化。这一步的处理时间，也要看具体的情况。
我们平时可以写好一些具体问题的处理步骤

解决到验证通过的时间，要看是可以直接改还是要打包升级，是随时可以处理还是要到凌晨业务不繁忙的时候处理。后两个过程的时间取决于工程师自身的技能经验和具体情况具体分析，先不做讨论。

书中所画的思维导图如下：