最近分析这几个事情其实感觉还是挺有关联的

• 每逢长假高速必堵。
• 每年一次体检，每年检查出的问题越来越多。
• 小问题不解决最终系统迎来了故障。海因里希法则 300:29:1

堵车是堵了慢还是慢了堵？

• 我从一直认为是有事故发生，堵着了。所以后面的车都动不了。但是后来自己开车时候发现。如果说从家到公司日常开车20分钟。但是一旦下雨天，就是1个小时甚至90分钟。而全程我都没看到一个事故，路上警车都没出现过。
• 而这些年看到不少短视频是无人机拍摄的节假日高速拥堵，最前面就是一些低速车占据着车道。后面越来越多的车辆就造成了拥堵。

一慢毁所有

• 这是我多年在PPT上反复出现的。也是我一直的观点。我们假设一个SQL执行要1秒，那么现在100个同时（我指的是同一秒）来执行还能保证所有都是1秒完成吗？基本都要变长，具体多长不太好量化。变慢10倍、20倍是可能的。如果是5秒的SQL，1000个一起执行呢？Oracle中有等待事件read by other session就可能出现了。在这种情况下我甚至遇到过宕机的事件。
• 同样的如果在以上场景下，我们把1秒的SQL，效率提到1ms。那么就是数据库排队串行执行1000个。也只要1秒。
• 问题来了，很多人觉得怎么可能做到1ms？其实只要需求合理情况下，通过巧妙设计是可以做到的。我经常看到数据库中小于1ms的高频SQL，这是真高频。一秒执行几万次的SQL。
• 其实这对数据库来说不算什么。
• 有时候我会听到人说，那么查询快。数据库写入慢，我怕来不及写入。我看了他的SQL是insert into select。。。。。 这哪里是写入慢，这分明是查询慢。这不是又回到了我说的一慢毁所有嘛。根本还是不会select。
• 对于当今的数据库和硬件来说，即使单次提交，每秒写入1000条数据不是问题。Exadata那种环境下每秒1万个事务都是稀松平常。
• 如果是批量写入提交那每秒几万几十万都不叫事。

然后我们说说体检

• 我今年体检一堆问题。有七八个指标都是在超过或者低于临界值上下1%-5%。对我来说这就不得了。（也许是我比较惜命）相当于在数据库可观测性上发现一些异常。我是非常重视的进行整改。
• 而日常我们系统中，别说高出5%，就是50%都没人当回事。其实如果说OLAP系统CPU90%也就算了。但是OLTP系统（几秒可能没事）长期高负荷系统就有隐患。慢到一定程度就是堵。高负荷的系统硬件使用寿命也降低。数据库中CPU超过50%以上就有一定程度的等待。
• 但是话说回来，总不能一直都是低，那么不是资源浪费吗？这里就要说到资源池削峰填谷，通过数据库的资源调度来处理。其实云原生数据库也是这样的动态分配。只是在本地部署的环境中数据库没有这种机制，那么注定是要有大量的浪费。除非将多个业务峰值有差异的系统放在一起，此消彼长。
• 我为什么强调高出一点就要引起重视。因为长期亚健康的人和系统一样。稍微再加一点波动就堵了。
• 有一次看到王坚的访谈，他提到从数据分析来说。并不是路面上车辆多了好多倍才导致拥堵，其实在杭州，只要比平时多10%的车上路，就会出现拥堵。所以本来如果0.5秒的SQL不去处理。可能因为数据量变大，导致现在0.7秒了。在访问量没有明显变化的前提下，IO增加了10%，CPU出现等待，相互影响，最后系统也出现了卡顿甚至宕机。

总结一下

• 因为慢才堵，SQL是根源，读取数据量过多导致。真实的需求一定不是大海捞针的检索，一定是通过高质量索引完成的。如果不是那需求基本就是扯淡，无法拿到台面上说的。
• 一慢毁所有，各种问题都出来了。有时候只要多一点，就会带来全局性的拥堵和等待。