物理读与逻辑读的概念在很多数据库中都存在，只不过针对PG这样使用DOUBLE BUFFER的数据库，物理读与逻辑读之间的开销差异并不是特别容易评估。Oracle对二者的差异就很容易评估了，物理读的平均IO延时在1-2毫秒左右，而逻辑读的延时要低数个数量级。不管如何，物理读的大小对于评估数据库性能来说还是有一定的意义的，无论是Oracle或其他使用DOUBLE BUFFER策略的数据库产品。一个有经验的DBA能够从物理读指标的变化中看出一些数据库存在的问题与隐患，在D-SMART中，也针对这个场景定义了故障模型，遇到物理读突增的情况会自动产生报警，并且提供一个完整的专家诊断建议。

我们今天以Oracle数据库为例，来探讨一下这个问题，其他数据库的诊断路径有些类似，比Oracle略微简单而已。引发此类问题的主要路径有5条，每条主路径上又会有几条子路径。因为图不能太大，我把四级以上的路径以及一部分三级路径都做了裁剪。一般来说，遇到这种场景，应用出问题的可能性比较大。因此最可能出问题的路径来自于物理读较大的TOP SQL，这些SQL可能是以前没有出现过，而突然出现的物理读极高的SQL，有可能是以前物理读不高，今天突然变高的SQL，这种情况很可能是执行计划出现了变化(往往系统中存在多种执行计划)，还有就是某条单次执行物理读并不太高，但是执行次数较多的SQL的执行次数发生了巨大的增长。如果这些问题存在，那么我们可以初步认为大概率情况是出现了应用的异常。但是哪怕这些问题真的存在，也并不一定说明根因就是应用的问题。因为DB CACHE、大事务异常、直接路径读异常等也可能是这个问题的根因。

通过这5条主路径，几十条三四级路径的分析，我们大致可以找出存在问题的点，但是哪个是因，哪个是果，还需要进一步的分析。

其实针对这个问题，我前几天针对日志分析的问题，发过今天有个网友给我留言，对于AIOPS中的专家知识还是算法方面提出了一些不同的看法。

我十分感谢这位朋友，只有经过不同观点之间的碰撞，才能把问题考虑得更为清晰，看到留言后，我也思考了很久。从留言上看，这位朋友很可能也是从事数据库行业的工作的，提出了数据库应该朝AIOPS方向发展，产品更智能化，更低TCO，实现弯道超车。这也是很多数据库企业与客户的期望。

我们目前遇到了一个知识障碍，以我目前对数据库问题分析的复杂性的认知，找不到特别好的自动化的方法来解决复杂性和多样性的问题。实际上Oracle提出自治数据库的概念也有好多年了，只是目前能够实现真正“自治”的能力也十分有限，Oracle的自治数据库的基础也是基于TIME MODEL这样的以OWI为基础的可观测性接口的深度统计的，实际上里面更多的还是对数据库产品自身规则的认知体现，和AIOPS还差的很远。

事实上目前我们的国产数据库最主要的问题是在底层的引擎的技术上与Oracle还有代差，比如SQL引擎对复杂计算的支持还不够好;算子分解，下推，并行处理的算法还比较简单;优化器还无法为某些SQL提供最佳的执行计划;SQL解析时还经常无法获得最佳的执行计划;存储引擎还无法更好的支撑某些高开销的计算;锁和闩锁的并发能力还不够强;DB CACHE的访问算法还不够优化;WAL的并发写入算法还不够高效，等等等等。如果不把这些底层基础打好，那么加持再多的AIOPS算法也是白搭的。

从另外一个角度上看，我们的数据库核心开发人员哪怕水平再高，也不大可能了解客户的各种应用场景，因此他们考虑问题的时候，或者在设计数据库产品的功能的时候，往往只能从一些基础的场景去考虑，因此在数据库核心引擎中植入AIOPS算法的难度也是相当大的，目前看到最多的还是在CBO优化器中引入一些AI的算法。实际上AI算法在CBO优化器中的引入最主要的场景还是多种执行计划的选择上，通过历史执行情况进行建模，为后续的SQL执行提供辅助。这对于某些核心SQL上面有一定的效果，不过真正在客户那边被用的很好的真实案例目前还相当少，实际上这也只是解决了很少一部分问题。在复杂SQL的执行计划选择上，最容易出问题的是HASH JOIN和NESTED LOOP JOIN的选择错误。针对这个问题，ORACLE 12C已经有了动态执行计划的解决方案，只是目前还不够成熟，经常出现误判，导致更严重的问题，因此在大多数客户的核心系统中，都是关闭此功能的。PG 数据库目前也有类似的插件，也是因为成熟度的问题，使用甚少。

不过CBO中引入再多的AI算法，如果CBO本身的能力不行，那也是白搭。这种需要简单高效的引擎中，AI算法大多数也只能是一些旁路的辅助功能，真正核心算法，还是应该以简要为主，基于规则是可控的，容易修正的，而基于AI算法作为核心，也许目前的AI技术还不足以支撑吧。

实际上，目前我们国产数据库最需要补的课是可观测性的增强，我和很多数据库核心研发人员讨论过，想要了解他们的数据库产品中某个指标或者某个等待事件代表的含义，以及在数据库中影响的因素，几乎没有一个人说的清楚，哪怕对着代码，也仅仅能够给出一些十分模糊的解释。这是因为我们的国产数据库产品连最基础的TIME MODEL都没有很好的构建起来，很多指标虽然统计了，但是某些指标的异常可能意味着什么，或者和数据库的哪个BUG有关，这些知识实际上都没有建立起来。连数据库厂商都解释不清的事情，那客户就用起来就更是一头雾水了。

AIOPS是好东西，弯道超车也是大家所期望的，我以前也曾经提过，弯道超车有几个条件，首先自己的车的速度比前车要快，最起码也是差不多的;其次自己的驾驶技术要够好，起码比前车要好;第三是存在合适的弯道，比较适合超车;第四是赛车手的感觉要好，能够捕捉到最佳的超车时机。当我们还被别人套着圈，人家的车速远远快于我们的时候，我们不考虑如何提高自己的驾驶技术和车子的基础水平，就想着弯道超车，恐怕最后也只能是空想。

国产数据库实现超车还是有可能的，在某些Oracle不擅长的领域实现超越和替代的例子已经很多了。而在主战场上，想要超车，恐怕还是先要先把内功练好。因为有着全世界最丰富的数据库应用场景，经过十几二十年的磨练，这一天有可能会到来。