"先止损 - 再定位 - 后根治 - 防复发" 的四步黄金流程 🚀
线上出问题,先保服务可用,再慢慢排查根因!
show full processlist;找到耗时 > 10s 的线程,kill [id]; -- 1. 查看当前运行的所有线程,快速定位慢SQL
show full processlist;
-- 2. 查看慢查询日志(必须提前开启,阈值建议设为1s)
show variables like 'slow_query_log';
show variables like 'long_query_time';
-- 3. 分析执行计划(最关键!)
explain select * from user where name = '张三';
-- 重点关注:type(是否range/ref以上)、key(是否走索引)、rows(扫描行数)、Extra(是否有Using filesort/Using temporary)
-- 4. 查看数据库状态
show status like 'Threads_connected'; -- 连接数
show engine innodb status; -- 查看事务和锁等待情况limit 1000000, 10 会扫描前 100 万行,性能极差 innodb_buffer_pool_size 不足常见原因 | 典型场景 | 解决方案 |
|---|---|---|
全表扫描 | where 条件无索引或索引失效 | 创建合适的联合索引,遵循最左前缀原则 |
索引失效 | 索引列用函数 / 运算、隐式类型转换、like '% xxx' | 避免在 where 子句中对索引列做操作,使用覆盖索引 |
大分页查询 | limit offset 过大 | 改用游标分页: |
N+1 查询 | 循环查询关联表 | 改用批量查询 |
大事务 | 一个事务包含多个操作甚至 RPC 调用 | 拆分大事务,将非数据库操作移出事务 |
锁等待 | 长事务持有行锁导致其他请求阻塞 | 优化事务粒度,避免在事务中做耗时操作 |

技术亮点:无需侵入业务代码,自动采集慢 SQL 并告警,提前发现潜在问题
@Configuration
public class DruidConfig {
@Bean
@ConfigurationProperties("spring.datasource.druid")
public DataSource druidDataSource() {
DruidDataSource dataSource = new DruidDataSource();
// 开启慢SQL统计,阈值1秒
dataSource.setSlowSqlMillis(1000);
dataSource.setLogSlowSql(true);
// 开启WallFilter,拦截全表扫描、恶意SQL
dataSource.setFilters("stat,wall,log4j2");
return dataSource;
}
// 注册Druid监控面板
@Bean
public ServletRegistrationBean<StatViewServlet> statViewServlet() {
ServletRegistrationBean<StatViewServlet> bean = new ServletRegistrationBean<>(
new StatViewServlet(), "/druid/*");
bean.addInitParameter("loginUsername", "admin");
bean.addInitParameter("loginPassword", "123456");
return bean;
}
// 自定义慢SQL告警器(生产级)
@Bean
public SlowSqlListener slowSqlListener() {
return new SlowSqlListener() {
@Override
public void onSlowSql(SlowSqlEvent event) {
String sql = event.getSql();
long timeMillis = event.getTimeMillis();
// 超过3秒直接发钉钉/企业微信告警
if (timeMillis > 3000) {
DingTalkAlertUtil.sendAlert(
"【严重慢SQL告警】\nSQL: " + sql + "\n耗时: " + timeMillis + "ms\n数据源: " + event.getDataSourceName()
);
}
}
};
}
}技术亮点:解决limit 1000000, 10全表扫描问题,支持任意深度分页
// ❌ 错误写法:扫描前100万行,性能极差
List<User> badPage(int pageNum, int pageSize) {
int offset = (pageNum - 1) * pageSize;
return userMapper.selectPage(offset, pageSize);
}
// ✅ 正确写法:游标分页(基于自增ID)
List<User> goodPage(long lastId, int pageSize) {
// 只扫描pageSize行,性能恒定
return userMapper.selectByCursor(lastId, pageSize);
}
// 对应的SQL
@Select("select id, name, phone from user where id > #{lastId} order by id asc limit #{pageSize}")
List<User> selectByCursor(@Param("lastId") long lastId, @Param("pageSize") int pageSize);技术亮点:将 N 次数据库调用合并为 1 次,减少网络 IO 和连接开销
// ❌ 错误写法:N+1查询(1次查订单列表,N次查用户)
List<OrderVO> badGetOrderList() {
List<Order> orders = orderMapper.selectAll();
return orders.stream().map(order -> {
OrderVO vo = new OrderVO();
BeanUtils.copyProperties(order, vo);
// 循环查询用户,N次数据库调用
User user = userMapper.selectById(order.getUserId());
vo.setUserName(user.getName());
return vo;
}).collect(Collectors.toList());
}
// ✅ 正确写法:批量查询(1次查订单,1次查所有用户)
List<OrderVO> goodGetOrderList() {
List<Order> orders = orderMapper.selectAll();
// 提取所有用户ID,批量查询
Set<Long> userIds = orders.stream().map(Order::getUserId).collect(Collectors.toSet());
Map<Long, User> userMap = userMapper.selectByIds(userIds).stream()
.collect(Collectors.toMap(User::getId, Function.identity()));
return orders.stream().map(order -> {
OrderVO vo = new OrderVO();
BeanUtils.copyProperties(order, vo);
vo.setUserName(userMap.get(order.getUserId()).getName());
return vo;
}).collect(Collectors.toList());
}技术亮点:用分段锁解决单条记录行锁竞争问题,QPS 提升 50 倍以上
// ❌ 错误写法:单条记录锁竞争激烈,数据库CPU飙升
@Transactional
public boolean deductStock(Long productId, Integer num) {
int affected = stockMapper.deductStock(productId, num);
return affected > 0;
}
// ✅ 正确写法:分段锁(将1条库存记录拆分为10条)
@Transactional
public boolean deductStockWithSegment(Long productId, Integer num) {
// 随机选择一个分段
int segment = ThreadLocalRandom.current().nextInt(10);
int affected = stockMapper.deductStockBySegment(productId, num, segment);
// 如果当前分段库存不足,尝试其他分段
if (affected == 0) {
for (int i = 0; i < 10; i++) {
if (i == segment) continue;
affected = stockMapper.deductStockBySegment(productId, num, i);
if (affected > 0) return true;
}
return false;
}
return true;
}
// 对应的SQL
@Update("update stock set stock = stock - #{num} where product_id = #{productId} and segment = #{segment} and stock >= #{num}")
int deductStockBySegment(@Param("productId") Long productId, @Param("num") Integer num, @Param("segment") Integer segment);技术难点 | 问题本质 | 典型场景 | 解决方案 | 排查 / 验证命令 |
|---|---|---|---|---|
隐式类型转换导致索引失效 | MySQL 对索引列做隐式函数转换,破坏索引有序性 | varchar 类型的手机号传了 int 值;int 类型的 id 传了字符串 |
|
|
联合索引最左前缀陷阱 | 范围查询(>、<、between)之后的索引列失效 | 联合索引 |
|
|
大事务导致的锁等待雪崩 | 长事务持有行锁时间过长,导致后续请求排队阻塞 | 事务中包含 RPC 调用、文件 IO、循环操作 |
|
|
死锁排查与解决 | 多个事务互相等待对方持有的锁,形成循环依赖 | 事务 A 先更新表 1 再更新表 2;事务 B 先更新表 2 再更新表 1 |
|
|
MySQL 查询优化器选错索引 | 统计信息不准确,导致优化器选择了错误的索引 | 数据分布不均匀,某列值大部分相同 |
|
|
Using filesort/Using temporary | 排序或分组操作无法使用索引,需要在内存 / 磁盘临时表中完成 |
|
|
|
“假设生产环境数据库突然告警,出现大量慢SQL,老板让你去排查。说说你的整体思路。”
“好的,我一般会按发现→定位→分析→优化→验证这样一个闭环来做。先用一张图概括:”

“接下来每一步都有具体的工具和检查点,我可以展开说说。”
“好,那第一步快速定位到具体是哪些SQL在慢,你会怎么做?”
“线上讲究无侵入快速定位,我一般四板斧:
pt-query-digest 直接看 TOP N,最省事。 sys.statement_analysis,能按总耗时排序,找出那些执行次数多、累积影响大的SQL。 SHOW FULL PROCESSLIST,看当前正在跑的SQL,重点盯 Sending data、Creating tmp table 这些状态。🎯 这一步结束,手里就是一份嫌疑SQL清单,包括耗时、频率、来源。”
“嗯,拿到一条具体SQL了,接下来怎么分析它为什么慢?”
“核心就是看执行计划。MySQL的话我优先用 EXPLAIN ANALYZE(8.0),因为它显示实际耗时和预估行数的误差。
然后逐字段排查,就像看化验单一样:”
关注字段 | 🚩 异常信号 | ⚠️ 实际意味着什么 |
|---|---|---|
type | ALL | 全表扫描,基本是索引缺失/失效 |
key | NULL | 完全没用到索引 |
rows | 巨大 | 扫描行数太多,估算可能不准 |
Extra | Using filesort / Using temporary | 文件排序或临时表,耗内存、磁盘 |
filtered | 很小 | 索引选择性差,大量数据回表后被丢弃 |
“同时我还会 SHOW CREATE TABLE 看一眼表结构和现有索引,确认是不是有索引但没用上,比如发生了隐式类型转换。”
“分析完执行计划,一般能归纳出哪几类根因?”
“根据经验,90%的慢SQL都跑不出这六大根因:
SHOW ENGINE INNODB STATUS 能看出来。 SELECT * 拖了大字段,或者深分页 LIMIT 100000,20 实际扫了很多行。 iostat、top 一起看。”“根因找到了,那你会立刻怎么优化?”
“优化分紧急止血和长远根治。我常用的‘三板斧’:
FORCE INDEX 止血,但事后要分析统计信息为啥不准。OR 条件改 UNION ALL。JOIN 替代部分子查询。 SELECT *,只查必要字段。“优化完了,怎么验证真的有效,而不是按下葫芦浮起瓢?”
“验证我严格走三步:
EXPLAIN 甚至 EXPLAIN ANALYZE,确认执行计划符合预期,实际耗时下降。 如果效果不理想,我会重新回到执行计划分析那一步,调整方案。”
“不错。最后用一句话总结你的排查思路。”
“监控先发现 → 工具抓SQL → EXPLAIN看计划 → 结合场景挖根因 → 建索引/改写法/调架构 → 验证闭环。永远先观测再动手,线上最怕凭直觉改代码。”
“思路很清晰。刚才你提到深分页优化、索引失效分析这些,能不能贴一段核心代码示例,展示一下你的具体实现?最好有技术亮点。”
“没问题,我挑两个最有代表性的场景。
这是典型的大表 LIMIT 100000,20 慢查询,传统做法数据库实际扫描了100020行。我用延迟关联改写:
-- ❌ 原始慢SQL(扫描大量行)
SELECT id, title, content, create_time
FROM articles
WHERE status = 1
ORDER BY create_time DESC
LIMIT 100000, 20;
-- ✅ 优化后:先取主键,再回表关联
SELECT a.id, a.title, a.content, a.create_time
FROM articles a
INNER JOIN (
SELECT id
FROM articles
WHERE status = 1
ORDER BY create_time DESC
LIMIT 100000, 20
) AS tmp ON a.id = tmp.id;💡 亮点:子查询只扫索引覆盖列(id + 索引列),避免了大量回表,再由主键直接关联取出最终数据,扫描行数从10万+降为20行左右。
线上有一个SQL突然从毫秒变秒级,执行计划显示 type=ALL。我怀疑是隐式类型转换导致索引失效,用这个查询验证:
-- 假设 phone 字段是 varchar,但传入的是数字
EXPLAIN SELECT * FROM users WHERE phone = 13800138000;
-- key: NULL, type: ALL 💢 索引失效
-- 验证转换发生
SELECT
COLUMN_NAME,
DATA_TYPE,
COLUMN_TYPE
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_SCHEMA = 'mydb'
AND TABLE_NAME = 'users'
AND COLUMN_NAME = 'phone';
-- 结果:varchar(20) 而传参是数字,MySQL会将字段转为数字比较,导致全表扫描🛠️ 修复:改成 phone = '13800138000',或代码层统一参数类型,执行计划立刻恢复。
当监控曲线抖动,不是单个SQL特别慢,而是高频SQL累积效应,我会用这条语句快速抓凶:
-- 按总延迟排序,找出最 “费时” 的 SQL
SELECT
query,
db,
exec_count,
total_latency,
avg_latency,
rows_sent_avg
FROM sys.statement_analysis
ORDER BY total_latency DESC
LIMIT 10;📊 这条能看到哪些SQL虽然单次不慢,但执行次数极高,拖垮整体性能,是优先治理的对象。”
“代码很扎实。那站在技术面试角度,你觉得在这个线上慢SQL排查场景里,最大的技术难点有哪些?你是怎么解决它们的?”
“这个场景确实有几个特别棘手的地方,我总结为三大难点:
难点 | 具体描述 | ✅ 我的解决方案 |
|---|---|---|
🔥 难点1:生产环境无法随意操作 | 不能跑 | ① 优先使用慢日志 + pt-query-digest 离线分析,零侵入;
② 在从库或预发环境回放慢SQL,安全地做 EXPLAIN 和压测;
③ 利用 |
🧊 难点2:索引失效原因隐蔽 | 隐式类型转换、字符集不一致、函数包装、统计信息不准等,仅看执行计划不够 | ① 对比 |
⏳ 难点3:优化效果需要量化验证,且不能回归 | 优化一个慢SQL可能影响其他查询,或者线上数据分布不同导致预期不符 | ① 在影子表或预发环境用真实数据量压测,对比 |
这三大难点背后体现的是线上操作的敬畏心和量化驱动的优化方法论,恰好是一线工程师区别于‘只会写SQL’的核心竞争力。”
“很好,既有落地代码又有抽象思考。这个问题我们就聊到这儿。”
【别走,交个朋友】
我是Rain ,一个喜欢把复杂技术讲透、让代码落地的实践者。
如果你厌倦了四处收集碎片化的八股文,想看看一线项目里真实的架构决策和踩坑记录,欢迎来我的公众号「Rain的Java大神之路」坐坐。每天一个知识点,程序员的加油站。
在这里,我会把每一次技术复盘、每一个项目的设计源码,毫无保留地分享给你。
🔥技术这条路很酷,我们结伴同行。
🚀Keep Coding, Keep Loving —— 与所有 Java 同路人共勉。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。