慢SQL是如何拖垮数据库的？

本文结合一个实际故障案例出发，从小白的视角分析慢SQL是如何打垮数据库并引发故障的。

一、案发现场

上午9:49，应用报警：4103.ERR_ATOM_CONNECTION_POOL_FULL，应用数据库连接池满。

上午9:49-10:08期间，陆续出现 4200.ERR_GROUP_NOT_AVALILABLE、4201.ERR_GROUP_NO_ATOM_AVAILABLE、4202.ERR_SQL_QUERY_TIMEOUT等数据库异常报警。

由于数据库承载了销售核心的用户组织权限功能，故障期间，期间销售工作台无法打开，大量小二反馈咨询。

上午10:08，定位到有应用基础缓存包升级发布，上午9点40刚完成最后一批发布，时间点相吻合，尝试通过打开缓存开关，系统恢复。

二、现场结论

对此次升级缓存包应用发布内容分析，发现升级的某个二方包中，删除了本地缓存逻辑，直接请求DB，而本次升级没有对请求的SQL进行优化，如下代码所示，该SQL从Oracle迁移到MySQL，由于数据库性能的差异，最终造成慢查询，平均一次执行2S多，大量慢SQL最终打挂数据库。

SELECT CRM_USER_ID AS LOGIN_ID, CRM_ROLE_ID AS ROLE_NAME, CRM_ORG_ID AS ORG_ID  , CONCAT(CRM_USER_ID, '#', CRM_ROLE_ID, '#', CRM_ORG_ID) AS URO  , CONCAT(CRM_ORG_ID, '#', CRM_ROLE_ID) AS ORG_ID_ROLE_NAMEFROM CRM_USER_ROLE_ORGWHERE IS_DELETED = 'n'  AND CONCAT(CRM_ORG_ID, '#', CRM_ROLE_ID) = '123#abc'ORDER BY ID DESC;

经过讨论排查分析，得出以下结论：

1. 之前逻辑走本地内存，本次升级中由于涉及到的某个二方库代码变更删除了本地逻辑改查DB。

2. 查询DB的SQL去O阶段没有进行优化，在MySQL下为慢SQL，大量慢SQL查询拖垮了数据库。

三、进一步的疑问

面对上述结论，作为数据库方面的小白，有以下几个疑问，感觉需要深入挖掘：

1. 这条SQL为何是慢SQL；

2. 发布的应用为非核心应用，只是与登录权限共用了一个数据库，当时发布应用的QPS只有0.几，为何可以把库打挂；

3. 之前已经申请过一波连接池扩容，从10扩到了15&