慢查询故障实战复盘
2022年双十一凌晨,某电商平台的数据库突然出现大量慢查询,平均响应时间从5ms飙升到30s。
监控告警疯狂弹出:慢查询数量超过5000条/秒,数据库连接池耗尽,所有业务请求超时。
技术团队排查后发现:一条看似简单的订单查询SQL,由于缺少联合索引,导致全表扫描50万行数据。
更可怕的是:这条SQL在白天流量低的时候执行很快,但大促零点流量高峰时并发执行,直接拖垮了整个数据库。
这次故障导致订单系统瘫痪1小时,直接损失约1000万元。
【面试官手记】
慢查询是数据库最常见的性能杀手。我面试过的候选人里,能说清楚"慢查询分析"的有50%,能说清楚"执行计划解读"的有30%,能说清楚"索引优化"的有20%。慢查询的关键词是早发现 + 快优化。
一、慢查询识别标准 🔴
1.1 慢查询定义
1.2 慢查询日志
1.3 pt-query-digest分析
二、执行计划解读 🔴
2.1 EXPLAIN详解
2.2 常见问题模式
2.3 SQL优化实战
三、索引优化方案 🟡
3.1 索引设计原则
3.2 索引优化案例
3.3 索引维护
四、生产避坑 🟡
4.1 慢查询的五大坑
坑1:SELECT * 全字段查询
坑2:隐式类型转换
坑3:分页深度过大
坑4:索引失效
坑5:没有监控
4.2 慢查询检查清单
五、真实面试回放 🟡
面试官:慢查询怎么分析和优化?
候选人(小张):分析三步:
一是开启慢查询日志。
二是用pt-query-digest分析。
三是用EXPLAIN看执行计划,重点关注type、key、rows、Extra。
优化方案:
一是添加合适的索引。
二是避免SELECT *,只查需要的字段。
三是改写SQL,避免函数运算。
面试官:怎么判断索引是否合适?
小张:看执行计划的type列。
const/eq_ref/ref是好的,range凑合,index勉强,ALL最差。
还要看rows扫描行数,越少越好。
Extra里出现Using filesort和Using temporary需要优化。
【面试官手记】
小张这场面试的亮点:
知道慢查询分析三步法
知道执行计划关键字段含义
知道索引优化的常见方法
慢查询是P6工程师必备知识点,能完整回答的候选人,说明有数据库调优经验。
慢查询的核心是早发现 + 快优化。记住三个要点:
- 分析工具:慢查询日志、pt-query-digest、EXPLAIN
- 优化方向:添加索引、减少返回、改写SQL
- 预防措施:Code Review、慢查询告警、定期分析
慢查询是数据库的隐形杀手,大促前必须全面排查。