本文结合一个实际故障案例出发，从小白的视角分析慢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 ,CONCAT(CRM_USER_ID，'#'，CRM_ROLE_ID，'#，CRM_ORG ID) AS URO ,CONCAT(CRM_ORG_ID，'#，CRM _ROLE_ID) AS ORG_ID_ROLE_NAME FROM CRM_USER_ROLE_ORG WHERE IS_DELETED ='n' AND CONCAT(CRM_ORG ID，'#'，CRM_ROLE ID) ='123#abc' ORDER BY ID DESC;
注：1 SELECT CRM_USER_ID AS LOGIN_ID, CRM_ROLE_ID AS ROLE_NAME, CRM_ORG_ID AS ORG
经过讨论排查分析，得出以下结论：
- 之前逻辑走本地内存，本次升级中由于涉及到的某个二方库代码变更删除了本地逻辑改查DB。
- 查询DB的SQL去O阶段没有进行优化，在MySQL下为慢SQL，大量慢SQL查询拖垮了数据库。
三、进一步的疑问
面对上述结论，作为数据库方面的小白，有以下几个疑问，感觉需要深入挖掘：
- 这条SQL为何是慢SQL；
- 发布的应用为非核心应用，只是与登录权限共用了一个数据库，当时发布应用的QPS只有0.几，为何可以把库打挂；
- 之前已经申请过一波连接池扩容，从10扩到了15，发布的应用线上有流量的机器不过7台，为何可以把数据库压垮；
- 事后复盘，发布前一天灰度时也有过慢SQL，为何当时没有压垮数据库；
