SQL 调优三板斧，拿好拿稳了

前言

大家都知道，至少老读者应该都知道，我是从网管，编程，DBA,数仓一路爬过来的。这么多年的风里雨里多少有些技术上的技巧可以分享给大家。还记得有个曾经抖落过一段小插曲吗，发生在网管装机那个时代。

装机对于那个年代来说，其实没有太大的悬念。但外行看着还是觉得很高深。我们拿出螺丝刀，把风扇，CPU,内存，硬盘拔下来的瞬间，大家都是觉得不可思议的。我能感觉到他们的心疼，毕竟一台PC还要7，8000的时候，被我这么折腾，还是心有余悸。

但是我们老手都知道，洗手，拆箱，插拔，只要不带电操作，安全得很。甚至只要听到BIOS(年轻人估计都不知道了吧）的三长两短声，立马可辨，是内存，还是硬盘有问题了。拆装到位，一击即中。

上面是硬件部分的维护，那到软件部分怎么样呢？网上不去，软件卡了，黑屏，蓝屏？套路与硬件故障排除一样，重插网线，重启电脑（万恶的Windows 98）,卸载软件重装，最后万灵的一招，PE重装系统，Ghost 备份！

现专注于数据库开发了，碰到性能有问题，其实和硬件故障排除并没有多大区别，也有个套路。鉴于我们SQL微信群新朋友的疑惑，没怎么读我以前的文章，所以不知道我曾经写过“SQL调优三板斧”，这里我就重提一下。

第一板斧

跟上不了网一样，第一件事情，大家会做什么？对，就是检查网线。

SQL查询太慢，你会做什么？肯定不是去看网线了，网线一断，你的SQL直接报timeout错误了，根本不给你往下执行的机会。

SQL查询太慢，我们要做的事情当然是去检查，当前的SQL是不是在跑？还是在等CPU中央司令员给你机会去跑。数据库有自己的任务分配系统，如果你的线程级别比较低，分配系统就不给你机会去执行，那也白搭。那就只能等着了。

同学可能不知道为什么要等待，而不是发完SQL就立即执行这个概念！

举例，如果我们的数据库有分布式的应用，比如读写分离，那么在系统正在执行读写分离的时候，会有大量的任务在跑，而且级别较高，占用的服务器资源就会很多，比如高CPU,高内存，高IO.这个时候，任何的查询都会被挂起，只有等待CPU/Memory/io的分配，才能 运行。

第二板斧

平时大家都是写 CRUD 的任务多，很少有人会去看数据库的实现代码。所以很多细节不会清楚。但很多厂商为我们做好了可以瞥一眼神秘的数据库引擎实现的地方，那就是 execution plan（执行计划）.

在执行计划中，我们可以看到数据到底存储在哪个硬盘位置，内核是如何读取这些硬盘位置的数据，数据加载到内存后，又经过什么算法来得到我们想要的计算结果。

这些数据库本身的内核代码及实现，都源于IBM的一篇论文（大家在关注本号的时候，都应该拿到这篇论文了）.

知道这篇论文非常重要，它能帮你理解，整个数据库至少引擎部分，是怎么工作的。结合各个数据库软件的执行计划，你就会知道计划的哪个部分，有很大的提升空间。再评估使用哪个手段去提升它。

第三板斧

第三板斧，有些深入细节了。运行时统计信息的采样分析。

我们从IBM的论文中，可以得到这么个启示。很多引擎的算法都得益于采集到的元数据统计信息。基于这些信息，引擎会自动选择最优的算法。

比如一张表的Country字段（存储国家信息），经过统计，只有3个国家，中国，美国，欧盟。其中包含中国的记录数占据了85%的数据，而其他两国都只有7%，8%的数据。

如果有查询需要查询包含中国相关的数据，那么采用全表/全索引扫描的方式会快很多，因为回表这部分（如果不知道回表，可以往前翻翻我的文章）的成本就被极大的节约了。一旦查询其他两国，那么使用索引搜索更快。你发现某个查询在查询包含中国相关数据时，执行计划走的是 index seek, 你就可以帮执行计划调整成 index scan 或者table scan了。（同样，如果不知道怎么调执行计划，可以翻翻我之前的文章）

结尾

总结下来，就是检查等待，分析执行计划，运行时统计信息采集。如果能从这三个方面去分段调试，肯定能找到80%的性能问题。