早期计算机都是单核串行机器，虽然比人利用算法器计算要快了很多倍，但是面对复杂的计算还是有点力不从心。1960 年代，电子计算机体系结构进入多处理器、并行处理探索阶段，研究者开始尝试把多个处理器组合在一起，希望依靠多 CPU 大幅提升程序运行速度。最初业界有一个朴素的认知：如果计算机有N 个处理器，速度就能提升 N 倍。人们简单认为只要增加处理器数量，性能就能线性增长。但工程实践中发现加速并不是现行的。

　　1967 年春季的美国信息处理协会（AFIPS）计算机会议上，IBM的资深架构师Gene Amdahl 发表题为《Validity of the Single Processor Approach to Achieving Large Scale Computing Capabilities》（单处理器方案实现大规模计算能力的有效性） 的经典论文。阿姆达尔参与 了IBM 360 系列大型机设计，长期研究并行处理性能瓶颈，在并行计算方面是当时的顶 级高手。他的观点是：无论增加多少处理器，程序里不可并行的串行部分会成为性能天花板，单纯堆砌处理器无法无限提升性能。

　　阿姆达尔本人依据该定律，倾向认为单处理器架构依然是大型计算最优路线，对大规模并行计算持悲观态度。因此在随后的计算机世界中，阿姆达尔定律被认为是一种过时的定律，而古斯塔夫森定律更加适合现实的IT世界。

　　不过阿姆达尔定律对于数据库优化来说，是很有启示的，二十多年前我在研究数据库优化的时候就接触过这个定律，它也让我建立起了和国内绝大多数做数据库优化的同行完全不同的优化理念和方法论体系。当年同行们都比较热衷于优化SQL，认为只要SQL优化好了，数据库的问题就基本上解决了。而我则更加注重应用系统中的“排队效应”。关于排队效应，可以参考我在2019年发的一篇文章《谈谈系统优化中的排队效应》（谈谈系统优化中的排队效应）。

　　基于阿姆达尔定律，我认为数据库整体性能上限，由系统中无法并行、串行执行的环节决定。单纯增加资源（更多 CPU、更多节点、更多分片）无法无限提升吞吐 / 延迟，必须先识别并削减串行瓶颈。

　　这个理论在工程落地方面，有几个十分有效的方法。在优化实施的时候优先消除串行瓶颈，再扩容资源，很多人做法：慢了就加 CPU、加副本、加分片。或者找几条SQL去优化一下。而根据阿姆达尔，只要串行段占比不变，扩容收益快速收敛。而哪怕因为优化了几条SQL缓解了这个瓶颈，未来一遇到新增的几条烂SQL，问题还是会再现。

　　锁与并发控制是隐形串行开销，闩锁冲突、行锁冲突、热点更新本质上制造串行化。因此在数据库系统中，哪怕硬件资源再丰富，同一行数据只能串行更新。因此在优化中，调整数据库的配置，尽可能避免闩锁冲突，在数据库表和索引上热点打散，在业务上队列削峰、分库分表隔离热点都是十分必要的优化手段。

　　数据库优化的顺序应该是：先找到并削减串行瓶颈（热点写入、全局锁、单点元数据、跨分片事务），再考虑扩容、分片、增加副本；只扩容不解决串行瓶颈，最终一定会撞上性能天花板。而SQL优化则应该作为一个常态化的工作，而非项目式优化的首选。在一个优化项目中，SQL优化应该是解决比较急迫的性能问题，或者作为项目锦上添花的工作，而不应该成为一个大型优化项目的主要工作。

　　随着国产数据库进入企业的核心领域，优化也成为国产数据库替代中的关键工作之一。在Oracle时代，我们可以用的优化手段十分丰富，但是到了国产数据库时代，似乎除了优化SQL，其他的工作能做的并不多。这种情况甚至让一些用户的IT管理人员都产生了错觉，我曾经与一个企业的IT部门负责人交流，在使用Oracle的时候，他们曾经是我做优化的客户。而今他的观点是：用上国产数据库以后，我感觉运维不是主要问题了，把运维要解决的问题前置，在开发阶段做好管控，做好优化才是根本。

　　这种观点似乎有点道理，不过以开发替代运维的做法成本之高，对于他们这种体量的企业，未来必然是无法承受的。现阶段，他们迁移的主要是核心系统，相对稳定，变更不多。而且数据库运维本身就有原厂服务驻场，有问题也有人背锅，所以他把管理重心前移也是能够解决他当前的问题的。但是未来怎么办？

　　国产数据库在上线后系统级优化能做的事情不多，并不说明国产数据库优于Oracle或者说国产数据库太简单，可做的系统优化不多。而是国产数据库厂商并未了解自己的数据库在各种场景中该如何优化才能消除阿姆达尔定律中所说的串行瓶颈，让硬件能够被充分使用起来。连原厂都不知道的优化技巧，让用户或者第三方去做难度颇大。

　　最近我正在做一些国产数据库优化的场景工具，不过总觉得能从原厂的官方网站上获得的经验和知识太少，让我感到无从下手。我觉得这也是国产数据库厂商必须抓紧研究的地方。