完结，但地图要常翻
从那条 8 秒的订单 SQL 开始，22 篇写完：索引、事务、锁、日志、主从、调优、治理、备份。最后一篇不添新知识，只做一件事——把散落的内容拼成一张出事时能直接翻的作战地图。未来你遇到问题，先查下面的症状索引，再跳对应篇目。
作战地图：症状 → 篇目 → 第一动作
| 症状 | 第一动作 | 复习篇目 |
|---|---|---|
| 接口变慢，不知道谁干的 | 开慢日志抓 SQL | 第 1 篇 |
| EXPLAIN 看不懂 | 先看 type、key、rows、Extra | 第 2 篇 |
| 建了索引还是慢 | 按失效写法清单排查 | 第 4、5 篇 |
| 走不走索引看心情 | ANALYZE TABLE + optimizer trace | 第 6 篇 |
| 数据对不上、口径飘忽 | 核对隔离级别与事务边界 | 第 7、8 篇 |
| Deadlock 报错 | SHOW ENGINE INNODB STATUS 看案发 | 第 9 篇 |
| 主从数据不一致 | 查 binlog 与两阶段提交配置 | 第 10 篇 |
| 改完读旧数据 | 延迟治理 + 写后读主 | 第 12、13 篇 |
| 主库挂了 | 按高可用选型预案切换 | 第 13 篇 |
| CPU 飙高 / 整体变慢 | sys.session + digest TOP SQL | 第 15 篇 |
| 连接打满、服务假死 | 池参数对账 + 治慢 SQL | 第 14、16 篇 |
| 翻页越深越慢 | 游标分页 / 延迟关联 | 第 18 篇 |
| DDL 卡死连坐全站 | 查 MDL 与长事务，换 gh-ost | 第 19 篇 |
| 表大到心慌 | 先过三道门槛再谈拆 | 第 20 篇 |
| 数据被误删 | 全量 + binlog 时间点恢复 | 第 21 篇 |
按生命周期阅读的路径
- 建表之前：第 17 篇（字段与表设计）——设计期省下的债不用还利息；
- 查询优化线：第 1 → 2 → 3 → 4 → 5 → 6 篇，慢日志到优化器的完整闭环；
- 事务并发线：第 7 → 8 → 9 → 10 篇，redo/undo 到 MVCC 到锁到 binlog；
- 高可用线：第 11 → 12 → 13 篇，搭建、延迟、切换三部曲；
- 调优工具线：第 14 → 15 → 16 篇，参数、仪表、连接池；
- 数据治理线：第 18 → 19 → 20 → 21 篇，深分页、大表 DDL、分库分表、备份。
三条心法
- 先测量，再动手：慢日志、EXPLAIN、sys schema 全都是测量的仪器。跳过测量直接「优化」，大概率是在给想象中的病灶开刀；
- 索引是 B+ 树，不是许愿池：最左前缀、覆盖索引、自增主键、索引失效——所有规则都能从「树按序组织、页按序 I/O」推导出来。忘掉口诀时，推一遍就回来了；
- 每个机制都标着价：MVCC 用存储换读并发，next-key lock 用锁范围换隔离，分库分表用 join 和事务换容量，双 1 用延迟换安全。没有免费的隔离级别，只有你愿不愿意付的账单。
上线检查清单
- 慢日志开启，long_query_time = 1；
- 核心 SQL EXPLAIN 验收：type 至少 range，高频查询无 Using filesort；
- 全库 utf8mb4，COLLATE 三层一致；
- 金额 DECIMAL，主键 bigint 趋势递增；
- 交易链路双 1（flush_log_at_trx_commit = 1，sync_binlog = 1）未动；
- Buffer Pool 按内存 50-70% 配置，命中率 99% 以上；
- 连接池上限与 max_connections 对过账，业务账号与运维账号分离；
- 从库 super_read_only 开启；
- 每日全量备份 + binlog 留存 + 异地，恢复演练做过至少一次；
- 主从延迟有 pt-heartbeat 级别的真实监控，而非只看 Seconds_Behind_Source。
Redis 缓存实战 16 篇、MySQL 实战 22 篇，两座系列地标在咖啡馆后山落成。下个系列候选还剩三块地：消息队列（Redis 系列第 7 篇和本系列第 10 篇都埋过钩子）、分布式 ID（第 20 篇挖了坑）、以及 Elasticsearch 检索实战。选哪块，你说了算——咖啡馆不着急，咖啡豆管够。
咖啡凉了，记得趁热喝。
评论 (0)