01 先上结论：一张图记住调优路线
慢查询日志 → EXPLAIN → 索引补齐 → SQL 改写 → 覆盖/物化 → 读写分离 → 监控闭环
把这 7 个节点背下来，90% 的性能问题都能一路绿灯。
02 真实案例：500 万订单表，20 s→0.2 s
| 阶段 | 动作 | 耗时变化 |
|---|---|---|
| ① 索引缺失 | 给 WHERE + JOIN 字段建联合索引 | 20.3 s→8.5 s |
| ② SQL 写法 | 小表驱动、先过滤再 JOIN | 8.5 s→2.3 s |
| ③ 覆盖索引 | 把 SELECT 列也包进索引，不回表 | 2.3 s→0.8 s |
| ④ 物化视图 | 小时级汇总表 + 定时刷新 | 0.8 s→0.2 s |
| ⑤ 读写分离 | 一主两从，读并发×3 | QPS 3k→9k |
| ⑥ 冷热归档 | 90 天前迁历史库，热表-70% | 备份 4 h→40 min |
结论：索引是根基，改写是利器，架构是护城河。
03 索引设计 10 条军规（背下来）
-
等值放左，范围放右；like 模糊查询
%放最右。 -
禁止对索引列写函数（
WHERE DATE(create_time)=...会全表扫描）。 -
OR 条件要么改 UNION，要么建合并索引。
-
无法覆盖就开启 ICP（Index Condition Pushdown）。
-
单表索引 ≤6 个；写多读少场景宁可砍掉。
-
长字符串用前缀索引（
url(20)）。 -
区分度 <10% 的字段不单独建索引。
-
联合索引顺序 = 查询字段顺序照抄。
-
ORDER BY 字段放联合索引尾部。
-
亿级表优先分区+局部索引，最后再分库分表。
04 SQL 改写 7 大套路
-
JOIN 代替相关子查询 → 半连接，索引可穿透。
-
小表驱动 → Straight Join 强制执行顺序。
-
延迟关联 → 深分页
LIMIT 1000000,10改“先拿 id 再回表”。 -
预聚合 → 提前
GROUP BY子查询，减少主查询行数。 -
UNION 代替 OR → 不同列 OR 拆 Union，各走各索引。
-
批量代替循环 → 一条 SQL 插 1000 行，减少 1000 次往返。
-
只查需要的列 → 杜绝
SELECT *，让覆盖索引成为可能。
05 执行计划“三看三改”
| 看 | 含义 | 怎么改 |
|---|---|---|
| type | 访问类型：ALL→index→range→ref→eq_ref→const→system | 越靠右越好，ALL 就加索引 |
| key | 实际用到的索引 | NULL 就是没用到，看 key_len 判断用了前几列 |
| rows | 预估扫描行数 | 扫描/返回 >20 倍就要改索引或 SQL |
06 高并发架构层兜底
-
主从 + 读写分离：Dynamic-datasource / ShardingSphere 路由。
-
连接池：HikariCP 大小 =
(CPU 核心×2)+有效磁盘数。 -
Redis 挡 95% 热读，Key 加版本号防穿透。
-
异步写：非关键路径先写 MQ，再异步落库，抗 10 倍峰值。
-
参数调优：
-
innodb_flush_log_at_trx_commit=2+sync_binlog=0（允许丢 1 s 日志，写性能↑30%）。 -
max_connections=1000，thread_pool_size=CPU 核数。
07 场景速查表（收藏备用）
| 场景 | 关键手段 | 收益 |
|---|---|---|
| 深分页 | 延迟关联 + 游标分页 | 10 ms→1 ms |
| 唯一检查 | 唯一索引 + INSERT IGNORE | 避免 SELECT+INSERT 竞态 |
| 热点行更新 | 拆成多条记录 / 分桶 | 并发↑5 倍 |
| 亿级大表 | 分区（RANGE/HASH）+ 局部索引 | 备份 8 h→1 h |
| 统计报表 | 小时级物化视图 + 定时刷新 | 30 s→200 ms |
08 一句话总结
“索引是根基，改写是利器，架构是护城河，监控是生命线。”
把这篇扔进收藏夹，下次慢查询别再到处搜语法，直接翻出来照抄即可。
如果对你有用，记得点个赞，评论区交流你的“秒优化”技巧！
