MySQL慢查询治理实战:故障止损、根因定位、SQL调优、事前防控完整手册
2026-08-19
157
线上系统经常出现一种诡异现象:系统刚上线性能尚可,随着业务数据量上涨,数据库CPU持续走高,部分接口响应越来越慢,严重时直接引发大量超时,甚至拖垮整个业务库⚠️。 很多故障并不是服务器硬件不足,而是慢SQL日积月累带来的恶果。一条未优化的SQL,在十万、百万级数据下,足以把数据库资源耗尽。 不少团队只懂得事后加索引临时救急,缺少完整的治理流程,同类故障反复复现。本篇文章完整覆盖故障应急、定位手段、调优技巧、代码改造、上线前置检查,提供可直接复制的SQL与Java代码,建立完整慢查询防护体系。一、慢SQL带来的线上真实危害💥数据库CPU持续打满,正常读写请求排队阻塞业务接口大面积超时,前端请求报错、页面加载缓慢锁等待、死锁风险上升,出现数据更新卡死主库压力过大,主从延迟持续扩大,读从库数据不一致严重场景直接数据库雪崩,整体业务不可用重点提醒:慢查询危害会随数据量放大,小数据环境测试完全正常,上线跑一段时间后才集中爆发。本地单元测试很难发现这类隐患。二、线上突发慢查询:第一步先应急止损✅线上故障优先保障业务可用,不要上来就调SQL、改索引,先止损再排查根因。1.查看数据库当前运行会话-- 查看正在执行的SQL,Time字段代表执行耗时(秒)SHOW FULL PROCESSLIST;找到执行时间很长的慢SQLID,执行kill杀掉会话,临时释放数据库压力。KILL 会话ID;2.业务侧临时应急手段对慢查询对应接口增加限流,避免大量请求压垮数据库热点查询临时上Redis缓存,绕开数据库查询非核心功能临时降级,优先保障核心业务流程三、如何精准捕获慢SQL🔍方式1:开启MySQL慢查询日志-- 查看慢查询配置SHOW VARIABLES LIKE 'slow_query_log%';SHOW VARIABLES LIKE 'long_query_time';-- 动态开启慢查询日志,执行超过1秒即记录SET GLOBAL slow_query_log = ON;SET GLOBAL long_query_time = 1;生产环境建议长期开启慢查询日志,长期收集耗时异常SQL,做到问题早发现。方式2:应用层Druid监控采集慢SQL(Java项目常用)Druid连接池可以配置SQL监控,设置阈值自动记录耗时过高SQL,不需要依赖数据库日志。spring: dat