企业官网建设流程全解析

视频看了几百小时还迷糊？关注我，几分钟让你秒懂！

在实际开发中，慢 SQL 是性能杀手的第一名！一个没加索引的WHERE条件，可能让接口从 10ms 变成 10s；一条全表扫描的JOIN，可能直接拖垮整个数据库。

本文将用通俗语言 + Spring Boot 实战代码 + 正反案例对比，手把手教你：

• 如何发现慢 SQL？
• 如何分析执行计划？
• 如何优化常见慢查询？
• 如何预防慢 SQL 上线？

小白也能看懂，建议收藏！

一、为什么慢 SQL 危害巨大？

🚫 反例：一个“无辜”的查询拖垮系统

// 用户服务：根据手机号查用户（看似正常） public User getUserByPhone(String phone) { return jdbcTemplate.queryForObject( "SELECT * FROM user WHERE phone = ?", new BeanPropertyRowMapper<>(User.class), phone ); }

问题在哪？

• 如果user表有 1000 万条数据；
• 而phone字段没有索引；
• 那么每次查询都要全表扫描，耗时可能 >5s；
• 高并发下，数据库 CPU 100%，整个系统雪崩！

✅结论：慢 SQL 不只是“慢”，而是系统性风险！

二、如何发现慢 SQL？

方法1️⃣：开启数据库慢查询日志（以 MySQL 为例）

-- 查看是否开启 SHOW VARIABLES LIKE 'slow_query_log'; -- 开启慢查询（临时） SET GLOBAL slow_query_log = 'ON'; SET GLOBAL long_query_time = 1; -- 超过1秒记录 -- 指定日志文件（可选） SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log';

生产环境建议开启，定期分析日志。

方法2️⃣：使用 Druid 监控（Spring Boot 集成）

前面我们讲过 Druid，它能自动记录执行时间超过阈值的 SQL。

# application.yml spring: datasource: druid: filter: stat: slow-sql-millis: 200 # 超过200ms算慢SQL log-slow-sql: true # 打印慢SQL日志

启动后，控制台会输出类似：

[Druid-ConnectionPool-Log] slow sql 256 ms, url:..., sql: SELECT * FROM order WHERE create_time > '2025-01-01'

方法3️⃣：APM 工具（如 SkyWalking、Arthas）

但对新手来说，Druid + 慢日志已经够用！

三、慢 SQL 优化四步法（核心！）

定位 → 分析 → 优化 → 验证

第1步：定位慢 SQL

通过上述方法找到具体 SQL。

第2步：分析执行计划（EXPLAIN）

EXPLAIN SELECT * FROM user WHERE phone = '13800138000';

重点关注：

• type：最好为const/ref，避免ALL（全表扫描）；
• key：是否命中索引；
• rows：扫描行数，越少越好；
• Extra：避免Using filesort、Using temporary。

✅理想结果：

type: ref key: idx_phone rows: 1 Extra: NULL

❌危险信号：

type: ALL key: NULL rows: 10000000 Extra: Using where

第3步：针对性优化（附正反案例）

✅ 优化1：添加缺失索引（最常用！）

反例（无索引）：

-- user 表 phone 无索引 SELECT id, name FROM user WHERE phone = '138...'; -- EXPLAIN 显示 type=ALL, rows=1000万

正例（加索引）：

ALTER TABLE user ADD INDEX idx_phone (phone);

再次 EXPLAIN，type=ref,rows=1，速度从 5s → 1ms！

⚠️ 注意：

• 索引不是越多越好！写多读少的表慎加；
• 避免在索引字段上使用函数，如WHERE YEAR(create_time) = 2025→ 索引失效！

✅ 优化2：避免 SELECT *

反例：

SELECT * FROM order WHERE user_id = 1001; -- 如果 order 表有 50 个字段，包含大文本（如 content）

正例：

SELECT id, order_no, amount, status FROM order WHERE user_id = 1001;

减少网络传输 + 内存占用，尤其当表有TEXT/BLOB字段时效果显著。

✅ 优化3：分页优化（深分页问题）

反例（经典慢查询）：

-- 跳过 10 万条，取 10 条 SELECT * FROM product ORDER BY id LIMIT 100000, 10; -- 随着 offset 增大，越来越慢！

正例（基于游标分页）：

-- 记住上一页最大 id = 100000 SELECT * FROM product WHERE id > 100000 ORDER BY id LIMIT 10;

时间复杂度从 O(N) 降到 O(1)，百万级数据也快如闪电！

💡 Spring Data JPA 可用Pageable+@Query实现，MyBatis 同理。

✅ 优化4：JOIN 优化

反例（大表 JOIN 大表）：

SELECT u.name, o.amount FROM user u JOIN order o ON u.id = o.user_id WHERE o.create_time > '2025-01-01'; -- 如果两表都千万级，且无索引，直接卡死

正例：

1. 确保order.user_id有索引；
2. 先过滤再 JOIN：

SELECT u.name, o.amount FROM user u JOIN ( SELECT user_id, amount FROM order WHERE create_time > '2025-01-01' ) o ON u.id = o.user_id;

✅ 优化5：避免隐式类型转换

反例：

-- phone 是 VARCHAR 类型，但传了数字 SELECT * FROM user WHERE phone = 13800138000; -- MySQL 会把 phone 转成数字比较 → 索引失效！

正例：

SELECT * FROM user WHERE phone = '13800138000'; -- 字符串必须加引号！

Java 中用PreparedStatement自动处理类型，但拼接 SQL 时要小心！

第4步：验证优化效果

• 再次EXPLAIN看执行计划；
• 实际执行时间对比（可用System.currentTimeMillis()测试）；
• 压测验证（如 JMeter）。

四、Spring Boot 中如何预防慢 SQL？

1️⃣ 开发阶段：集成 MyBatis 拦截器打印执行时间

@Component @Intercepts({@Signature(type = StatementHandler.class, method = "query", args = {Statement.class, ResultHandler.class})}) public class SqlCostInterceptor implements Interceptor { @Override public Object intercept(Invocation invocation) throws Throwable { long start = System.currentTimeMillis(); Object result = invocation.proceed(); long cost = System.currentTimeMillis() - start; if (cost > 200) { System.out.println("【慢SQL警告】耗时: " + cost + "ms"); } return result; } @Override public Object plugin(Object target) { return Plugin.wrap(target, this); } }

超过 200ms 自动告警，早发现早治疗！

2️⃣ 测试阶段：SQL 审核工具（如 SOAR、Archery）

但小团队可用人工 Code Review + EXPLAIN 检查。

3️⃣ 上线前：压测 + 监控

• 使用 JMeter 模拟高并发；
• 观察 Druid 监控面板是否有慢 SQL；
• 设置数据库 CPU/连接数告警。

五、常见误区 & 注意事项

❌ 误区1：“加了索引就一定快”

• 如果查询返回 80% 的数据，MySQL 会放弃索引，直接全表扫描（因为回表成本高）；
• 复合索引顺序很重要：WHERE a=? AND b=?，索引应为(a,b)，不是(b,a)。

❌ 误区2：“IN 比 OR 快”

• 小集合（<100）两者差不多；
• 大集合 IN 可能更优，但最好用 JOIN 代替大 IN。

⚠️ 注意：

• 不要在事务中执行慢 SQL，会锁表/锁行，阻塞其他请求；
• 定期 ANALYZE TABLE更新统计信息，让优化器选择正确索引。

六、总结：慢 SQL 优化 Checklist

记住：90% 的慢 SQL，靠一个正确索引就能解决！

视频看了几百小时还迷糊？关注我，几分钟让你秒懂！