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

忘是亡心i 2023-09-26 23:08 82阅读 0赞

本文结合一个实际故障案例出发，从小白的视角分析慢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等数据库异常报警。

![21d5e6c2c985570363f446e683feada7.png][]

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

上午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&\#

[21d5e6c2c985570363f446e683feada7.png]: https://img-blog.csdnimg.cn/img_convert/21d5e6c2c985570363f446e683feada7.png