如何解读“过早优化是万恶之源”这句话

　　数据库该怎么用其实也是一个争议挺大的话题，很多人可能会不理解为啥数据库还要那么用而不是这么用。因为每个用户的技术背景不同，团队的技术特点不同，开发团队的能力不同，所使用的数据库的技术能力特点不同，所使用的数据库管控平台不同，使用数据库的方式以及对数据库的技术要求也是不同的。

　　2006年左右，Oracle ACS的一个朋友找到我约一篇稿子，他希望我能写篇关于数据库优化越早越好的文章。当时约稿的目的是因为很多大客户的数据库应用搞得太不讲究，性能存在较大的问题，ACS的工程师在给客户做巡检的时候，需要花大量的时间帮用户解决一些十分低级的性能问题，他们认为这些问题原本是可以在系统开发时解决掉的。他们希望让用户在开发应用时多考虑考虑性能优化的问题，让Oracle能够用得更好，从而能够降低Oracle售后服务的压力。于是我写了一篇题为《应用系统生命周期和Oracle数据库优化》的文章，发表在《Oracle技术通讯》上了。

　　当时的小型机与现在的服务器相比，性能上差距很大，大多数企业用户使用能够的Oracle 9i与现在的Oracle也无法同日而语，因此那时候Oracle对于大用户还是不敢提SQL随便写这种 建议的，因此需要引导用户在系统建设前期开展优化工作。随着X86替代小型机以及Oracle数据库技术的不断进步，Oracle数据库的整体处理能力有了脱胎换骨的变化。大多数Oracle用户都可以更加自由地编写应用了，哪怕应用的质量不是很高，Oracle也能够尽可能让系统跑得能够使用。

　　对于一般的企业来说，业务才是生存之道，数据库只是辅助业务开展的一种IT基础设施，应该与服务器、网络设备一样简单。作为IT基础设施的数据库的这种进步，让那些系统数据量不是特别大，研发技术能力相对较弱的企业可以更加低成本地进行应用系统的研发，更加关注于业务本身。

　　与“系统优化从需求开发开始”的观念相反的是克努特优化原则 (Knuth's optimization principle)中提到的“过早优化是万恶之源”（实际上这句话最早是最早由Tony Hoare说的，只是在Knuth的书中第一次提到）。Knuth认为过早的把时间与成本浪费在过度精细的优化考虑上，会导致不必要的浪费，因为某些你担心的性能问题很容易在被发现后解决掉。

　　一个是2006年时Oracle ACS提倡的“系统优化从需求开始”，一个是2019年Knuth大师所说的“过早优化是万恶之源 ”，我们该如何判断哪个观点是正确的呢？其实你一旦在判断哪个观点是正确的 ，那么你已经陷入到错误的认知中去了。在不同的背景条件下，在不同的应用场景中，在不同的技术背景下，答案本身就是不同的。

　　Oracle ACS观点的背景是计算资源十分昂贵，研发团队技术能力不足，应用系统复杂而高聚合，应用开发迭代缓慢，缺乏敏捷开发能力。而Knuth观点的背景是开发十分敏捷，应用系统微服务化，计算资源在云上弹性获得，修复性能BUG十分快捷。在这两种不同的背景下，对于同一个问题自然就有不同的答案。

　　不过我还是觉得Knoth老爷子对这个问题的关键有些极端，其实我理解的这句话也是有场景的，指的是在开发过程中。他希望开发人员不要在开发初期“过早地考虑优化的问题 ”。而“系统优化从需求开始”是因为一些不懂IT的领导和用户提出一些对性能恶化影响甚大的需求来。比如一次查询可能涉及几十年时间窗口的数据，这必然会导致大数据量的扫描，消耗大量的CPU和IO资源，而限制最多查询一个月数据可以确保索引访问的高效性。

　　二十多年前一个系统上线第一天就崩溃了 ，我被紧急叫去帮助分析。后来我发现系统的首页上有大量的统计汇总数据，而且每隔一分钟自动刷新一次，而大多数用户使用完某个功能后都会退回到首页，因此整个数据库在不停地做统计分析。而这个明显不合理的设计居然源于某个平时压根不会使用这套系统的领导。

　　在三十多年的IT生涯中，我从一个总想把每件事搞个明明白白的小白变成了一个不太喜欢争吵的人，因为我明白每个人眼前的风景不同，每个人对美的定义不同，因此每个人都会说自己看到了最美的风景，对此无需争论。