主题
MySQL 学习路线
从「一组 SQL 怎么变成可靠的数据」出发,按日志与并发的因果链排列。先读 01–04 建立机制,再读 05–06 解决查询性能,最后看 07–09 的同步、生产与监控问题。
适用版本:MySQL 8.0(InnoDB);8.4 的差异在各篇单独标注,未标注处以官方文档为准。
篇目
| 编号 | 篇目 | 回答的问题 |
|---|---|---|
| 01 | 事务特性 | 一组 SQL 为什么能要么全成、要么全败,提交后为什么不丢 |
| 02 | MVCC 多版本并发控制 | 读和写为什么可以不互相阻塞,快照是怎么来的 |
| 03 | 锁 | 当前读和写靠什么保证正确,为什么会阻塞和死锁 |
| 04 | Redo Log 与 Binlog 两阶段提交 | 崩溃恢复和主从复制如何共用一次提交 |
| 05 | 索引与 B+ 树 | 为什么三次磁盘 IO 能查到千万行,回表与覆盖索引是什么 |
| 06 | SQL 调优与 EXPLAIN | 一条慢查询怎么定位、怎么改写 |
| 07 | Canal 数据同步 | 如何从 Binlog 做近实时的下游同步 |
| 08 | MySQL 生产踩坑 | 长事务、误删、MDL、自增耗尽、选错索引怎么处置 |
| 09 | 监控指标与告警 | 盯哪些指标、什么先兆会导致雪崩、先限流还是先扩容 |
| 10 | 读写分离与多数据源 | 主从延迟下怎么避免读到旧数据,多数据源怎么路由与切换 |
| 99 | 生产检查清单 | 上线前、运行中、故障时逐条核对 |
推荐顺序
先打机制(01–04),再看性能(05–06),最后进入生产与数据链路(07–10),检查清单收尾。
为什么这样排
事务是问题的起点:一组写操作必须原子、并发执行必须互不干扰、提交后必须扛住崩溃。
- 原子性和隔离性把问题推到 Undo + MVCC + 锁:02 讲快照读,03 讲当前读,两者合起来才是完整的隔离性。
- 持久性把问题推到 Redo + Binlog:04 讲一次提交为什么要两阶段,以及崩溃后怎么判断该提交还是回滚。
- 机制清楚后再看性能:05 讲索引结构,06 讲优化器怎么选、慢查询怎么改。
- 07–09 是机制在生产、数据链路和监控里的延伸,遇到具体故障再回查前面几篇。
怎么用
- 想理解「数据为什么不丢」:01 → 04。
- 想理解「并发为什么不出错」:01 → 02 → 03。
- 想解决「这条 SQL 为什么慢」:05 → 06。
- 想接下游缓存/搜索/数仓:04 → 07。
- 想提前发现雪崩、设告警:08 → 09。
- 想拆读写或接多个库:04 → 10,先看复制延迟再决定路由方式。
- 上线或排障:直接看 99,再回到对应正文查原因。
按问题找篇目
| 现象或问题 | 先看 |
|---|---|
| 提交后机器断电,数据会不会丢 | 01、04 |
| 两个事务改同一行,谁先谁后 | 03 |
| 同一事务两次查询结果不一样 | 02 |
| 磁盘被 Undo 撑满 | 01、02、08 |
| 一条 SQL 突然变慢 | 06、08 |
| 从库数据和主库对不上 | 04 |
| 要把变更同步到 ES/Redis | 07 |
| 怎么提前发现雪崩、告警阈值怎么设 | 08、09 |
| 上线前不知道检查什么 | 99 |
读完之后
能用自己的话回答四个问题,说明主线已经打通:
- 一次提交为什么要写两种日志,崩溃发生在中间会怎样。
- 快照读和当前读分别由什么保证,为什么需要两套机制。
- 一条查询走不走索引,取决于索引结构和优化器成本里的哪些因素。
- 长事务为什么会同时伤害磁盘、查询和 DDL。