慢SQL引发的重大生产事故

场景还原

在一个普通到不能再普通的晚上，线上的告警打破了这美好的下班时间，业务群里也炸了，赶紧掏出电脑，打开日志平台，日志显示数据库连接数被打满，这个时候我们都还没想到是慢SQL导致数据库被打满，错误如下图所示：

线上获取连接超时模拟图

直到DBA一个电话打来，你们业务的SQL扫描了几十亿行，赶紧处理下，现在已经影响到整个数据库集群了。（后面才知道我们公司的数据库虽然是主从集群，但是部署我们的集群的物理机上也耦合了其他业务的数据库集群，并不是完全分开的）DBA也是当机立断跟我们确认后立马kill了所有存量查询，但是线上慢SQL依然在新增，线上环境依然不容乐观。

我们也是立马介入分析，排查原因，我们从DBA提供的慢SQL入手，出乎意料是SQL只是一句简单的两个表关联查询，并不是想象中的非常复杂的查询，我们拿着SQL在线上查看了执行计划，展示的结果是驱动表扫描了几万行，被驱动表扫描了十几万行，那乘起来就是几十亿了呀，DBA的统计平台并没有出错。

我们找到了产生慢SQL对应的代码，因为是简单的查询，没有很快想到什么优化的空间，并且这块也不能直接屏蔽掉，因为如果屏蔽掉势必会导致服务大量报错，这些方案都行不通，然后这个时候我们才想到看下两个表的索引，看能不能尽量的降低扫描行数，令人没想到的是这个