去O的时代，搞好SQL优化不就好了?

最近我在和一些国产数据库厂商交流，希望能够更深入的了解指标、等待事件背后的一些技术细节，从而构建健康模型、故障模型和知识图谱。很多DBA和原厂工程师表示不太理解为什么我们要去研究这些细节。有位原厂工程师说：“国产数据库和开源数据库相比 Oracle来说简单多了，一般情况下把SQL优化好就可以了，没必要去做这些细枝末节的东西。”

实际上在Oracle时代，也有很多DBA认为Oracle 优化只要做好SQL优化，大部分问题就都迎刃而解了。确实是的，在很多情况下，应用写得好一点，系统就不容易出问题。可能对于某些DBA来说，他们面对的系统都是可以用SQL优化去解决的。我经历过的优化案例多一些，因此遇到过很多SQL优化解决不了根本问题的系统。

大概八、九年前，一个客户的Oracle数据库经常宕机，甚至有时候连aix系统都登录不上去了，只能把P780关机重启才能解决问题，折腾一次就是一两个小时的业务停机。我帮他忙分析了一下，发现出问题的时候AIOSERVER的数量很高，这个问题肯定是和IO有关的。经过仔细分析，发现他们的数据库是使用文件系统的，不过没有开启DIRECTIO，因此当IO负载很高的时候，异步IO启动了大量的AIOSERVER，从而阻塞了系统。因此我提了两点优化建议，一个是优化应用，降低IO负载。第二个是启用DIRECTIO。用户接受了第一个建议，要求开发商优化应用，但是不接受第二个建议，他们觉得第二个建议只是优化了IO性能不好时的系统性能，不是彻底解决问题的办法。经过SQL优化后，系统确实稳定了一些，不过宕机故障还是没有消除，三五个月还是会来上一次。

随着系统越来越复杂，哪怕SQL优化做得再好，IO负载还是在继续上升，系统故障的频率更为频繁了。于是他们才想起了我当时的第二条建议，试着启用了DIRECTIO，于是这个问题再也没有出现过。虽然应用优化可以降低IO的总量，但是无法定量的控制IO的总量，因此从系统层面去做优化才能真正解决这个问题。

也有朋友会说，这不还是O时代的方法吗。都去O了，现在的开源数据库和国产数据库都远没有O记这么复杂，现在我们可以专心去做SQL优化了吧。我的第二个例子讲的就是一个和PG兼容的国产数据库的事情。用户的应用优化得还可以，大多数SQL都是不太复杂的小查询，不过业务逻辑很复杂，每个交易执行的小SQL数量极多。系统上线两年后，突然变得不稳定起来，业务时快时慢，而且每天业务高峰一来，必然会有这种波动。有一次我给他们做国产数据库优化的培训，他们就顺便问了我这个问题。经过分析我发现SQL的执行计划没有问题，表的数据量也是基本稳定的。只是当业务高峰的时候，backend刷脏块的比例特别高，大量的脏数据都是backend写入的。这就会导致backend申请shared buffers的效率大幅下降，从而引发SQL响应时间的抖动。通过调整了bgwriter和checkpoint相关的参数，同时大幅度加大了shared buffers的配置（原配置是按照PG官方文档，设置为物理内存的25%），这个问题就消除了。

在去O的时代，很可能大多数数据库的性能问题可以通过SQL优化去解决，不过对于一些关键的核心系统，仅仅做好SQL优化还是不够的，这时候理解数据库的原理，能够从数据库的指标和等待事件中发现系统可能存在的隐患，并且找到优化的方法，对于数据库运维与优化来说依然是十分重要的。目前很多国产数据库并没有十分准确的将数据库的问题反馈到指标的波动和等待事件上，因此我们很难从中发现SQL以外的问题，让我们只能通过优化SQL去优化数据库。在一些技术沙龙上，我看到的一些比较“高级”的系统优化，都是基于一些DBA不太擅长的技术来完成的，perf/bpf等工具去做跟踪是很常见的分析方法。利用火焰图去找到数据库中的BUG更是令人叹为观止。不过对于一般的DBA，只能依靠这些闻所未闻的工具，那是何等的痛苦啊。我想能用这些工具发现问题的人，大多数应该也是能够理解数据库核心代码的，这些人要想出现在用户的运维人员里面，那真的是一个奇迹。

几年前我去拜访一个用户的时候，正好遇到他们使用的一个国产分布式数据库出现严重的性能，原厂的工程师也坐在电脑前一筹莫展，一大堆甲方围在他身边，焦急的询问他到底问题出在哪了。他说，他也不清楚，系统出现性能抖动，应该很快会自动恢复。不过能不能快速恢复，需要几分钟能恢复，他也不清楚。

我想新系统上线时应该还不太容易出事，运行上三五年，各种毛病就会出来了。现在去O向国产数据库迁移也是如此。我们的国产数据库厂商是不是也尽快把这方面的工作做好，别让广大的客户只能靠着优化SQL续命。