从运维的角度看数据库的可观测性

面试的经历可能大多数 DBA 都有过，实际上现在的面试题越来越不靠谱，有时候完全按照技术去回答还真的没法答好。昨天一个百度的哥们发了条微博，说早上他面了一个阿里的工程师，把他问的面红耳赤退出了。下午他去阿里面试，面试官正好是上午那个哥们，那哥们把上午他的问题抛出来让他回答，他也回答的乱七八糟的。这件事肯定不是真的，不过是在吐槽面试题的奇葩。

正好昨天一个网友说他前几天去面试，面试官问他一道题目，他回答后面试官就让他回家等消息了，然后就没消息了。这几天他一直在为这道题目困扰，想了很久，也咨询过很多人，找不到问题的关键。这道题目的原文如下：

翻译成中文就是：“想象有一个表存储所有用户的余额信息。 并且大部分 select 和 update 查询都与一条记录相关（例如公司账户余额 / 机构用户频繁交易），因此这些查询需要一个接一个地执行。 您可以做些什么来提高这些查询的性能？”。

这是一个日常比较难以遇到的应用场景，不过面试题一般都会从比较古怪的角度来出。我问他当时的回答，他说当时觉得虽然有点难，但是还是回答出来了。 1 ）利用索引提高每个查询的效率； 2 ）确保 SQL 使用了最佳的执行计划； 3 ）在应用程序上采用批量更新，而不是一个一个的执行。

这是一个从程序员的角度来说的不错的回答，不过如果作为优化工程师或者 DBA 来所，就不够合格了。实际上这个问题的变种是有个应用频繁的查询和更新某些用户余额，我们有什么办法来进行优化。如果问题仅限于此，那么这个问题就是我们日常十分常见的热块问题了。 Hot Block/page 或者 Buffer Busy Waits 这类问题，对于每个 DBA 来说可能都不难解决，提高 BUFFER 命中率、使用 hash 分区等方法打散热块、降低数据块的 fillfactor(PG 数据库 ) 或者加大 PCTFREE(ORACLE) 等都是优化的方法。同时提高 DB CACHE 的命中率，提高 IO 性能，从总体上降低 DB CACHE 负担也是可实施的而优化方案。

面试题往往不会出的太简单，因此这道题上加了点码，把问题集中到一个更为不常见的场景，那就是所有的查询操作或者并发写操作都几种在其中某一条记录上。在实际场景种会出现一个比较接近的场景，那就是某银行的余额表上突然出现大量的 buffer busy waits ，等待时间很长，导致了性能问题。平时的时候虽然余额表上的热块冲突也比较严重，不过还能接受，当某几个账号突然出现十分频繁的高并发操作，就有可能出现这种情况。如果放在一个全面的场景种去考虑这个问题，这个问题还是有解的，解答的方案和前面说的降低热块冲突的方案类似。

这种因为修改某种余额而导致的严重性能问题，十多年前我在一个运营商那里也遇到过，运营商的预付费卡的话费余额表也有类似的问题，当我们打电话的时候，随时都要更新这个余额，当余额不足的时候，会掐断这个通话，这是融合计费里的常见场景。早期的这个业务的实现是通过访问 Oracle 数据库来实现的，因此这个功能经常导致严重的性能问题。当时我帮这个运营商做优化，采用上述方法后虽然有效果，不过还是无法根治，因此我建议他们把这部分业务放到内存数据库种去，后来他们改造了应用，效果很好。

如果极端到了所有的读写操作都几种在其中某一个账号上，那么这个问题似乎又更加复杂了。不过从 DBA 的角度还是可以想出几条特殊的优化方法。我当时给他的建议是：

1 ）首先确保索引数量不要太多，冗余的索引会加大 BUFFER BUSY ；

2 ）其次是使用 HASH 分区或者降低 fillfactor(POSTGRESQL) 或者提高 PCTFREE(ORACLE ），其他数据库类似。从而降低某一行的冲突

3 ）访问该记录的索引如果不经常做范围扫描，那么可以创建反转键索引，进一步减少 BUFFER BUSY;

4) 通过系统级调整，降低 LATCH(Oracle ）、 LWLOCK(Postgresql ）、 spinlock （ Mysql ）的争用，从而减少 BUFFER BUSY WAITS 的延时；

5 ）提升 IO 性能；

6 ）如果上述方法都无效，那么最好是把这个业务放入 KV 的内存数据库，比如 Redis 中去做处理。

这实际上是一个十分开放的问题，上面也不是标准答案，面试官要的并不是你的正确答案，而是面对这种特殊场景，你的知识能够组织出来的调整方案。只要你不交白卷，同时掌握了分析这个问题的要点“ BUFFER BUSY” ，“ HOT RECORD ”，同时你的方案都是围绕这个要点的优化来进行的，那么可能面试官给你的分数也不会太低。