SQL优化方法论

知识点概述：SQL虽然实现简单却极易引发性能问题，当系统数据量、并发访问量上去后，不良 SQL 就会拖跨整个系统，我们甚至找不出哪些 SQL 影响了系统。即便找到也不知如何动手优化。 SOL 优化是一个复杂的工程。指导SQL优化的方法论是什么？

您好，这个微课重点讲解SQL优化方法论。

假如你已经知道系统的问题出在数据库。那请问，是SQL还是其他问题，你如何定位，如何判断？在假设你通过努力判断出是SQL问题，那该如何优化，是手动改写，还是不用改写，加加索引啥的……

SQL 优化并不简单，做好SQL优化需要掌握数据库体系结构、表和索引设计、高效 SQL写法、高级 SQL语法、多种优化工具等知识，甚至还得分析业务特点，以及了解优化器的缺点。只有建立SQL优化方法论体系，才能够迅速找到最适合的方法来优化SQL ，从而解决由SQL引 发的性能问题。这些都比编写SQL本身要复杂得多，因此要成为SQL优化高手仅知道一点优化基础是远远不够的，还需要经验的沉淀，并且要转化成你的方法论。由于不改写SQL通常来说比改写高效，而不改写的优化一般都和数据库的体系逻辑架构有关。不过能不改写优化固然好，有时等价改写也是必需的，而且改写分为两部分：一个是等价改写；一个是根据业务改写。业务改写是优化的最高境界，和开发人员交谈后发掘出真正的需求，然后写出来的代码表面上看和旧代码逻辑完全不等价，实际却等价。

做事要有方法论，要先整体后局部，解决问题要注意效率，先尽量考虑不改写的优化，再考虑改写的优化。而不改写的优化靠的是体系结构知识的沉淀，而改写则要考虑逻辑等价改写和业务改写两大思路。其中业务改写是SQL优化的最高境界。

以不同调优场景，可分为单纯（局部）场景的优化和复杂（整体）场景的优化。局部分析调优使用的工具，这个其实是在说SQL的执行计划了，这是SQL优化最重要的手段之一，通过分析执行计划，可以知道SQL的访问路径，知道它慢在哪里，从而进行SQL优化。整体调优工具，先撇开主机，网络，存储等层面的因素，暂时从数据库的整体层面入手，主要工具有AWR，ASH，ADDM，AWRDD这四个工具。

基于这些场景的工具应用，就是针对单纯场景的优化和复杂场景的优化手段。单纯场景其实可以理解为无菌真空实验室里的实验。比如一条SQL很慢，原因是未走高效的索引查询而走全表扫描，加个索引就快了，执行速度从10s变成了0.1s；或者是SQL执行速度被控制在1s左右，逻辑读控制在50个左右，应该就可以了。复杂场景就是刚才加了索引后，本应该从10s变为0.1s，结果还是10s，甚至更慢，这是咋回事了？原来，现在系统整体出了问题，数据库主机资源耗尽，啥语句都跑不快，还有那个逻辑读在 50 左右的 SQL ，如果一天执行几百几干万次，这要是能将逻辑读降低一点，得省多少的逻辑读啊。要考虑 SQL 本身没问题而是被环境影响，还要考虑到执行频率，判断其调优价值与调优空间，这些在单纯的环境里，是不用考虑的。

对我们学习也是有规律可循的。首先是获取系统整体信息的手段，一般是通过报表和日志获取。好比破案一样，这就是收集证据的阶段。接下来要找到蛛丝马迹，那就是如何发现问题。其实数据库性能工具的应用（报表获取和关注点）和体检是非常类似的。我们去医院体检，最终会得到一份体检报告，往往能看到很多总体性指标 这些指标会判断你是否健康。没毛病最好，万一有毛病，报告里要进一步判断是什么毛病，是高血压，还是骨质增生，还是胃有毛病……这就是现实中的体检报告。假设体检报告说你有胃病 很可能只告诉你胃有问题。却无法告诉你具体啥毛病 因为你手上的体检报告不会详细到拥有你胃部所有相关指标。你要得到这些指标需要做进步信息收集，那就是胃镜。做完后医生发现你胃部有大量息肉无法判断这些息肉是否为良性。于是还要做进一步的检查，这就是活检。如果患者拿着有各种晦涩指标的体检报告来到门诊请教医生，他一定会关注各种指标来判断患者具体是什么毛病。同样你也会对 Oracle 性能报告中的各种指标进行关注来判断数据库出了什么毛病。两者非常类似，关注不同的指标。

我练我掌握，总结一下自己平时工作中是如何sql优化的指导方法，对本讲的内容进行简单应用，巩固提升，最后，祝同学们学习进步！

参考文档：《收获，不止SQL优化》