MySQL 学习进阶之路：从 SQL 到生产级数据库工程

学习 MySQL 不是把命令表背完，而是建立一条完整的因果链：业务模型如何变成表和索引，SQL 如何经过优化器执行，InnoDB 如何保证事务和持久化，复制与备份如何保证恢复能力，最后如何用监控、容量和预案控制生产风险。

一、路线定位

这份路线适合：

• 会写基础 SQL，但还不够了解执行计划和索引的人。
• 负责 MySQL 安装、备份、复制和故障处理的运维/SRE。
• 需要设计表结构、事务边界和高并发方案的后端工程师。
• 准备从“会操作”进阶到“能独立负责生产数据库”的 DBA/DBRE。

路线以 MySQL 8.4 LTS 为主线。8.4 是长期支持版本，适合需要稳定生命周期的生产环境；创新版本适合验证新特性，不应只看版本号大小决定是否上生产。

完成后应具备以下能力：

1. 能把业务需求转换为合理的数据模型、约束和索引。
2. 能读懂 SQL 执行计划并定位慢查询、锁等待和资源争用。
3. 能解释 InnoDB 的事务、日志、MVCC 和崩溃恢复机制。
4. 能独立设计备份、恢复、复制、故障切换和升级方案。
5. 能建立监控、容量、安全、变更和演练体系。
6. 能根据一致性、延迟、吞吐和成本选择单机、主从、MGR、分片或分布式数据库。

二、总体学习地图

阶段	核心目标	建议周期	主要产出
0 基础准备	建好可重复的实验环境	3-5 天	Docker/虚机、账号、样例库、初始化脚本
1 SQL 熟练	能写正确、可读、可验证的 SQL	2-4 周	SQL 练习集、慢查询改写记录
2 数据建模与事务	能设计约束、事务边界和一致性方案	3-5 周	ER 图、索引设计、隔离级别实验
3 MySQL 与 InnoDB 运维	理解架构、日志、备份和恢复	4-6 周	备份恢复演练、升级检查表
4 性能与故障诊断	能用证据定位瓶颈和锁问题	6-8 周	Explain 报告、故障复盘、基线与容量报告
5 高可用与扩展	能设计复制、切换和扩展架构	8-12 周	主从/MGR 拓扑、切换演练、压测报告
6 生产架构与工程化	能治理数据库平台和长期风险	持续	Runbook、SLO、演练、成本与安全体系

不要严格按周打卡。每一阶段的真正毕业条件，是能够用实验数据解释“为什么这样做”，而不是记住某个参数值。

三、阶段 0：建立实验环境

学习目标

• 能快速创建和销毁 MySQL 8.4 实验实例。
• 能区分宿主机、容器、数据目录、配置文件和日志文件。
• 能安全保存实验数据，不把生产配置直接复制到测试。

推荐环境

开发机或虚拟机
├── mysql-8.4-primary
├── mysql-8.4-replica
├── mysql-shell
├── percona-toolkit
├── sysbench
├── mysqlslap
└── 监控与日志目录

Docker 适合快速实验，但生产实验还要覆盖：

• systemd 管理服务。
• 数据目录和 binlog 的磁盘规划。
• 独立账号、权限和 TLS。
• 备份文件与实例数据分离。
• 网络延迟、磁盘 I/O 和故障注入。

基础验证

SELECT VERSION();
SELECT @@version_comment, @@version_compile_os;
SHOW VARIABLES LIKE 'datadir';
SHOW VARIABLES LIKE 'log_bin';
SHOW VARIABLES LIKE 'innodb_buffer_pool_size';
SHOW VARIABLES LIKE 'transaction_isolation';
SELECT @@sql_mode;

阶段验收

• 能在一台机器上启动两套互不干扰的 MySQL 实例。
• 能说明数据目录、错误日志、慢日志、binlog 和 relay log 的作用。
• 能创建一个只读账号、一个应用账号和一个备份账号，并验证最小权限。

四、阶段 1：SQL 从会写到写对

学习目标

• 掌握 SELECT、INSERT、UPDATE、DELETE、JOIN、子查询和窗口函数。
• 理解 NULL、字符集、排序规则和隐式类型转换。
• 能写出可审查、可解释、可测试的 SQL。

必学内容

1. 查询基础

   • WHERE、GROUP BY、HAVING、ORDER BY、LIMIT。
   • 内连接、左连接、反连接和半连接。
   • 子查询、派生表、CTE 和窗口函数。
   • EXISTS、IN、NOT IN 在 NULL 语义下的差异。

2. 写入与约束

   • 主键、唯一键、外键、检查约束和默认值。
   • 批量插入与逐行插入。
   • INSERT ... ON DUPLICATE KEY UPDATE 的风险。
   • 逻辑删除与物理删除。

3. 可读性

   • 明确列名，不使用无约束的 SELECT *。
   • 不依赖隐式排序，分页必须稳定。
   • 统一别名、大小写、日期格式和命名约定。
   • 对结果集做边界和异常数据验证。

高频练习

-- 每个部门最近 30 天订单金额和订单数
SELECT
  d.id AS department_id,
  d.name AS department_name,
  COUNT(o.id) AS order_count,
  COALESCE(SUM(o.amount), 0) AS amount_total
FROM departments AS d
LEFT JOIN orders AS o
  ON o.department_id = d.id
 AND o.created_at >= CURRENT_TIMESTAMP - INTERVAL 30 DAY
GROUP BY d.id, d.name
ORDER BY amount_total DESC, d.id;

-- 查看每个用户最近一次订单
WITH ranked_orders AS (
  SELECT
    user_id,
    id,
    amount,
    created_at,
    ROW_NUMBER() OVER (
      PARTITION BY user_id
      ORDER BY created_at DESC, id DESC
    ) AS rn
  FROM orders
)
SELECT user_id, id, amount, created_at
FROM ranked_orders
WHERE rn = 1;

常见错误

• NOT IN 遇到 NULL 后结果不符合直觉。
• 分页只按非唯一字段排序，翻页出现重复或漏数。
• 用函数包住索引列，导致无法有效使用索引。
• 在业务代码中拼接 SQL，造成注入风险和计划缓存污染。
• 只看结果正确，不看扫描行数、临时表和排序代价。

阶段验收

写出 20 条覆盖多表关联、聚合、窗口函数、更新和删除的 SQL，并为每条记录：

• 业务含义。
• 预期结果。
• 边界条件。
• 可能的索引需求。
• 备选写法及取舍。

五、阶段 2：数据建模、事务与一致性

学习目标

• 能把业务实体、关系和生命周期转成可靠的数据模型。
• 理解 ACID、隔离级别、锁、MVCC 和死锁。
• 知道什么时候应保留范式，什么时候要有理由地反范式。

数据建模顺序

1. 识别实体、关系、唯一性和生命周期。
2. 画出 ER 图和状态转换。
3. 确定主键、唯一键和删除策略。
4. 选择字段类型和字符集。
5. 设计访问模式、查询路径和索引。
6. 设计事务边界、并发冲突和补偿方案。
7. 评估数据量、增长率、归档和分片阈值。

类型选择

数据	推荐	说明
自增标识	BIGINT UNSIGNED	考虑长期容量，不要默认用有符号小整数
业务字符串 ID	VARCHAR 或 BINARY	长度和排序规则必须明确
金额	DECIMAL	不在数据库中用浮点数表达精确金额
时间	DATETIME 或 TIMESTAMP	统一时区语义和精度
布尔状态	TINYINT 或枚举表	明确状态机和非法状态
半结构化数据	JSON	只用于确有必要且可查询的字段
大对象	对象存储或分表	避免把大二进制直接塞进行记录

字符集优先 utf8mb4，排序规则根据业务选择。不要混用不同字符集，否则连接、比较和排序很容易出现隐式转换。

事务与隔离级别

必须能解释：

• 原子性、持久性、隔离性和一致性分别依赖什么机制。
• READ COMMITTED 与 REPEATABLE READ 的快照和锁行为差异。
• 快照读与当前读的区别。
• 间隙锁、临键锁、插入意向锁和唯一键冲突。
• 死锁为什么可能发生在顺序不同的更新中。

-- 查看事务隔离级别和自动提交
SELECT @@transaction_isolation, @@autocommit;

-- 显式事务：先在两个会话中重复实验，不要只读结论
START TRANSACTION;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
UPDATE accounts SET balance = balance + 100 WHERE id = 2;
COMMIT;

锁实验

设计三个会话：

1. 会话 A 开启事务并更新一行但不提交。
2. 会话 B 更新同一行或相邻范围，观察等待。
3. 会话 C 查看 performance_schema.data_locks、data_lock_waits 和 information_schema.innodb_trx。

需要记录：

• 等待的是哪把锁。
• 谁持有锁。
• 事务当前状态。
• 最终是提交、回滚还是死锁。

阶段验收

• 为一个订单系统画出 ER 图和状态机。
• 写出主键、唯一键、外键和索引设计说明。
• 用两个并发事务复现一次脏写、不可重复读或死锁。
• 为一段跨表业务设计事务边界和失败补偿。
• 解释为什么“事务越长越安全”是错误认识。

六、阶段 3：MySQL 架构、InnoDB 与运维

学习目标

• 理解 MySQL Server 与存储引擎的职责边界。
• 理解 InnoDB 的页、索引、日志、缓冲池和崩溃恢复。
• 能完成安装、配置、账号、备份、恢复和升级。

MySQL 逻辑架构

客户端
  -> 连接层：认证、权限、连接管理
  -> SQL 层：解析、优化、执行
  -> 插件与存储引擎层
  -> InnoDB：表空间、页、索引、事务、日志
  -> 文件系统与持久化设备

重点问题：

• 一条 SQL 从客户端到结果返回经过哪些阶段。
• 优化器为什么可能选错索引。
• 查询缓存为什么不再作为通用性能手段。
• binlog、redo log 和 undo log 分别解决什么问题。

InnoDB 必学内容

1. B+ 树与聚簇索引

   • 主键索引叶子节点保存完整行。
   • 二级索引保存索引列和主键值。
   • 回表、覆盖索引和索引下推。
   • 为什么无序 UUID 或随机字符串主键可能造成页分裂和空间碎片。

2. Buffer Pool

   • 脏页、干净页、预读和刷脏。
   • 命中率不是唯一指标，还要看 I/O、延迟和写入压力。
   • 观察 Innodb_buffer_pool_read_requests 与 Innodb_buffer_pool_reads。

3. 日志与恢复

   • redo log 保障崩溃恢复。
   • undo log 支持回滚和 MVCC。
   • binlog 用于复制和时间点恢复。
   • checkpoint、刷盘和 innodb_flush_log_at_trx_commit 的一致性权衡。

4. 表空间

   • 系统表空间、独立表空间和通用表空间。
   • ibdata1、.ibd、undo 表空间和临时表空间。
   • 文件增长、碎片、压缩和回收空间。

账号与权限

CREATE USER 'app_rw'@'10.%' IDENTIFIED BY 'replace-with-secret';
GRANT SELECT, INSERT, UPDATE, DELETE
  ON commerce.* TO 'app_rw'@'10.%';

CREATE USER 'backup_ro'@'localhost' IDENTIFIED BY 'replace-with-secret';
GRANT SELECT, RELOAD, PROCESS, SHOW VIEW, TRIGGER, EVENT, LOCK TABLES
  ON *.* TO 'backup_ro'@'localhost';

权限原则：

• 不使用 % 放行所有来源。
• 业务账号只授予必要库和必要动词。
• 管理账号、复制账号、备份账号分开。
• 轮换密码和证书，记录权限变更。
• MySQL 8.4 默认安全策略更严格，不要为了兼容旧客户端直接降级认证。

备份与恢复

备份必须回答：

• 是全量还是增量。
• 是一致性快照还是逻辑导出。
• 包含哪些库、表、触发器、事件和账号。
• 备份文件多久保留。
• 能否恢复到指定时间点。

常见方式：

方式	适用	代价
逻辑导出	小库、结构迁移、部分对象	恢复慢，CPU 和 I/O 高
物理热备	大库、线上恢复	工具、版本和平台复杂
快照	云盘和存储层能力	依赖底层快照一致性
Clone	快速搭建副本	依赖版本和配置
binlog 归档	时间点恢复	必须持续校验和保序

恢复演练

每季度至少做一次：

1. 从全量备份恢复空实例。
2. 回放 binlog 到指定时间点。
3. 校验表数量、行数、校验和和关键业务数据。
4. 记录 RPO、RTO、失败点和操作耗时。
5. 更新恢复 Runbook，而不是只记录“恢复成功”。

升级原则

• 升级前阅读对应版本升级说明和弃用项。
• 先在克隆环境验证 SQL、复制、备份、监控和客户端兼容。
• 备份、回滚路径和只读窗口必须提前确认。
• 不用“版本更高”替代兼容性验证。

阶段验收

• 能从空机器部署一套 MySQL 8.4 并实现安全初始化。
• 能解释一条更新语句对 redo、undo、binlog 和脏页的影响。
• 能完成一次全量恢复和时间点恢复。
• 能根据业务目标设置 RPO 与 RTO。

七、阶段 4：性能优化与故障诊断

学习目标

• 从“感觉慢”转成“有证据地定位瓶颈”。
• 能区分 SQL、索引、锁、I/O、CPU、内存、网络和复制延迟。
• 能建立慢查询基线、容量趋势和回归测试。

诊断顺序

1. 确认影响范围：单请求、单 SQL、单实例还是全局。
2. 记录时间线：从何时开始，是否伴随发布、变更或流量增长。
3. 查资源：CPU、内存、磁盘延迟、吞吐、连接数和网络。
4. 查 SQL：慢日志、performance_schema、sys、事务和锁。
5. 用 EXPLAIN 和 EXPLAIN ANALYZE 验证执行路径。
6. 做最小变更实验并复测，保留前后证据。

慢日志

SHOW VARIABLES LIKE 'slow_query_log';
SHOW VARIABLES LIKE 'long_query_time';
SHOW VARIABLES LIKE 'log_queries_not_using_indexes';
SHOW VARIABLES LIKE 'log_slow_extra';

抓取重点是：

• 总耗时和平均耗时最高的 SQL。
• 扫描行数远大于返回行数的 SQL。
• 临时表、文件排序和临时磁盘使用。
• 同一类 SQL 的不同字面量是否产生不同计划。
• 发布后新增或突增的 SQL 指纹。

执行计划

EXPLAIN FORMAT=TREE
SELECT o.id, o.amount
FROM orders AS o
WHERE o.user_id = 1001
  AND o.created_at >= '2026-01-01'
ORDER BY o.created_at DESC
LIMIT 20;

至少解释以下字段：

• type 和 access_type。
• possible_keys、key、key_len。
• rows 和实际行数。
• filtered。
• Extra 中的覆盖索引、回表、排序、临时表。
• EXPLAIN ANALYZE 中的实际耗时、循环次数和缓冲区。

索引设计

联合索引接近“最左前缀”原则，但不是死记口诀：

• 等值条件优先，范围条件通常放在后面。
• 排序和分组要考虑索引顺序。
• 高选择性和低选择性列都可能有用，取决于查询模式。
• 覆盖索引能减少回表，但会增加写入和空间成本。
• 索引不是越多越好，写入放大和优化器选择空间都是成本。
• 统计信息不准时，优化器可能误判。

锁与死锁

关键系统表：

SELECT * FROM information_schema.innodb_trx;
SELECT * FROM performance_schema.data_locks;
SELECT * FROM performance_schema.data_lock_waits;
SHOW ENGINE INNODB STATUS;

定位时记录：

• 等待事务和被等待事务。
• 锁对象、锁模式和锁范围。
• 事务开始时间与空闲时间。
• 业务代码中的加锁顺序。

死锁处理不是简单重试。要先确认：

1. 事务是否足够短。
2. 加锁顺序是否一致。
3. 是否存在无法走索引的更新。
4. 是否因为唯一键冲突导致额外锁。
5. 重试是否幂等并有上限。

资源配置

重点观察：

• innodb_buffer_pool_size 与实例内存。
• 连接数、线程缓存和连接池是否匹配。
• innodb_io_capacity 与实际设备能力。
• 日志文件大小、刷盘策略和写入峰值。
• 临时表、排序缓冲和大量并发查询。
• 是否把操作系统缓存、页缓存和数据库缓存重复估算。

故障案例必须亲手做

每个案例都要记录时间线、指标、SQL、日志和修复措施：

1. 缺少索引导致全表扫描。
2. 函数包索引列导致索引失效。
3. 深分页导致大量回表和排序。
4. 长事务阻塞 DDL。
5. 两个事务反向更新触发死锁。
6. Buffer Pool 不足导致读 I/O 激增。
7. 备库延迟导致读到旧数据。
8. 批量写入冲垮磁盘和日志。

阶段验收

• 能根据慢日志给出可复现的优化前后对比。
• 能从 EXPLAIN ANALYZE 解释成本来源。
• 能定位一次锁等待并给出代码级修复建议。
• 能制定索引变更、回滚和观察窗口。

八、阶段 5：复制、高可用与扩展

学习目标

• 理解主从复制、GTID、半同步和组复制的边界。
• 能设计故障切换、备份恢复和一致性校验。
• 能判断读扩展、分区、分片和分布式数据库是否真的需要。

复制基础

SHOW REPLICA STATUS\G
SHOW MASTER STATUS\G
SHOW BINARY LOGS;
SHOW PROCESSLIST;

需要掌握：

• 主库 binlog、从库 relay log 和 SQL 线程。
• 基于位点和基于 GTID 的复制差异。
• 异步、半同步和组复制的持久性边界。
• 复制过滤、级联复制和多源复制。
• 从库延迟的常见原因及测量方式。

高可用架构

方案	特点	适用
主从 + 人工切换	简单、可控	中小规模、可接受人工窗口
MHA/Orchestrator 类编排	自动选主和切换	传统主从集群
InnoDB Cluster/MGR	多成员一致性复制	需要组复制和自动成员管理
MySQL Router	应用侧路由和读写分离	InnoDB Cluster 通常配合使用
代理层	路由、连接池、限流和故障转移	连接治理和多实例接入
分片	水平拆分数据	单实例容量和写入上限明确被触达

高可用不是“装一个工具”。切换必须具备：

• 唯一的主库判定机制。
• 旧主库隔离和防双写。
• 应用连接重新路由。
• 复制状态和数据一致性校验。
• 切换前后监控、日志和业务验证。

故障切换演练

至少演练：

1. 主库进程停止。
2. 主库网络不可达。
3. 从库延迟时发生故障。
4. 切换后应用只读、只写和事务失败。
5. 旧主库重新加入。
6. 切换过程中备份和 binlog 归档是否连续。

备份与复制组合

高可用不等于有备份：

• 复制能抵抗单机故障，但不能抵抗误删和逻辑损坏。
• 备份能恢复历史，但不能自动提供持续可用性。
• binlog 是时间点恢复和复制的重要桥梁。
• 克隆可以帮助快速搭建新副本，但不能替代长期归档。

扩展顺序

优先考虑：

1. 优化 SQL 和索引。
2. 调整事务边界和批量大小。
3. 读写分离。
4. 缓存和异步处理。
5. 归档冷数据。
6. 分区或垂直拆分。
7. 水平分片或迁移到分布式数据库。

分片会永久增加跨片事务、路由、扩容、备份和 SQL 限制，不应作为第一反应。

阶段验收

• 搭一套主从或 MGR，能解释状态和故障处理。
• 完成一次自动切换演练并记录 RTO。
• 验证从库延迟、网络中断和磁盘满时的行为。
• 能给出为什么不选择分片的容量分析。

九、阶段 6：生产级数据库工程

目标

从“处理单个实例”升级为“治理数据库平台”。

必备体系

可观测性

• 可用性、连接数、QPS、TPS、错误率和延迟分位数。
• InnoDB 缓冲池、锁等待、redo、undo、临时表和磁盘队列。
• 复制延迟、binlog 增长、备份成功率和恢复点。
• 以业务事务为单位的端到端延迟。

变更管理

• Schema 变更先评审，再灰度，再观察。
• 大表 DDL 评估锁、复制、磁盘空间和回滚。
• 应用 SQL、连接池、索引和版本一起发布。
• 保留变更前后指标和回滚证据。

容量管理

• 预测数据增长、binlog 增长和备份增长。
• 计算主从带宽、磁盘 IOPS、连接数和故障切换余量。
• 容量告警区分“接近阈值”和“预计何时耗尽”。

安全与合规

• 最小权限、TLS、审计和密钥轮换。
• 敏感字段识别、脱敏、加密和访问留痕。
• 备份文件、日志和监控标签不泄露秘密。
• 把恢复演练纳入合规证据。

稳定性工程

• 定义数据库 SLO，而不是只监控进程存活。
• 建立故障等级、升级路径、值班手册和复盘模板。
• 定期做备份恢复、主从切换、磁盘故障和网络分区演练。
• 用混沌实验验证系统，而不是只验证正常路径。

跨数据库比较

学习 MySQL 后，再比较：

• PostgreSQL：复杂查询、类型系统和扩展能力。
• Oracle：企业功能、PL/SQL 和成熟运维体系。
• TiDB/OceanBase：分布式事务、水平扩展和兼容性边界。
• Redis：缓存、数据结构和内存成本。
• ClickHouse：列式分析和高吞吐聚合。

比较维度应是数据一致性、访问模式、扩展方式、运维成本、生态和迁移风险，不是简单看基准测试排名。

十、六个月系统训练计划

月份	重点	必须完成
第 1 月	SQL、数据类型、约束	20 组查询练习、50 条数据初始化、执行计划入门
第 2 月	数据建模、索引、事务	ER 图、联合索引实验、隔离级别和锁实验
第 3 月	InnoDB、日志、备份恢复	安装双实例、物理/逻辑备份、PITR 演练
第 4 月	性能诊断、锁和资源	慢日志分析、Explain Analyze、死锁复盘、压测基线
第 5 月	复制、高可用、切换	主从或 MGR、延迟处理、切换演练、一致性校验
第 6 月	架构、容量、治理	容量报告、Runbook、SLO、故障演练和综合项目

每周建议节奏：

• 2 小时阅读官方文档。
• 3 小时设计和执行实验。
• 2 小时分析日志和指标。
• 1 小时写结论、复盘和更新知识库。

十一、实验项目清单

项目 1：电商订单库

设计：

• 用户、商品、库存、订单、订单明细、支付、退款。
• 唯一键、外键或应用层约束的选择。
• 订单状态机、幂等键和金额精度。
• 按用户、时间和状态的查询路径。

验收：

• 所有查询有执行计划。
• 能解释热点行和并发更新风险。
• 能设计归档和冷热数据分层。

项目 2：慢查询与索引优化

构造百万行数据，制造：

• 全表扫描。
• 回表放大。
• 深分页。
• 临时表和文件排序。
• 统计信息偏差。

输出优化前/后的 SQL、Explain、耗时、扫描行数和回滚方案。

项目 3：备份恢复与时间点恢复

完成：

• 全量备份。
• 增量或 binlog 归档。
• 误删除恢复。
• 恢复到指定时间点。
• 数据校验和恢复报告。

项目 4：主从与故障切换

完成：

• 主从搭建。
• GTID 验证。
• 延迟注入。
• 主库进程和网络故障。
• 应用重连和旧主库隔离。
• 切换复盘。

项目 5：容量与稳定性报告

输出：

• 当前数据量和增长率。
• QPS、TPS、连接、IOPS、延迟和 binlog 增长。
• 6/12 个月容量预测。
• 单点故障和演练结果。
• 需要改造的优先级。

十二、能力自测表

能力	入门	熟练	生产负责
SQL	能写查询	能改慢 SQL	能设计查询契约
建模	能建表	能权衡范式	能设计生命周期
事务	知道 ACID	能分析锁和死锁	能设计一致性边界
InnoDB	知道 B+ 树	能分析日志和缓冲池	能处理崩溃恢复
备份	会导出导入	会 PITR	能定义 RPO/RTO
性能	会看慢日志	会做基线和压测	能治理容量和变更
复制	会搭主从	会处理延迟	能设计切换和一致性策略
高可用	知道主从架构	会 MGR/Router	能演练和运营切换
安全	会建账号	能最小权限	能审计、轮换和合规
工程化	会写命令	会写 Runbook	能建立平台与 SLO

达到“生产负责”不等于知道所有答案，而是能定义风险、获取证据、执行变更、验证结果并在失败时恢复。

十三、推荐学习材料

官方文档

• MySQL 8.4 Reference Manual
• InnoDB Storage Engine
• Replication
• Group Replication
• MySQL Performance Schema
• MySQL Shell
• MySQL Router
• MySQL Backup

工具文档

• Percona XtraBackup
• Percona Toolkit
• gh-ost

学习方式

• 先读官方概念章节，再做最小实验。
• 每个参数都记录版本、默认值、生效范围和回滚方式。
• 用生产相似数据量做测试，不要只测 100 行。
• 用图表记录吞吐、延迟、I/O、内存和复制延迟。
• 把事故复盘写成可执行 Runbook，而不是只写结论。

十四、常见误区

• 只背命令，不理解状态和因果链。
• 认为主从复制等于备份。
• 看到慢 SQL 就加索引，不先看执行计划和业务目标。
• 认为 EXPLAIN 的估算行数一定准确。
• 把所有性能问题归因于数据库，不检查应用事务和连接池。
• 为了“高可用”堆组件，却没有切换演练。
• 过早分片，永久承担分布式复杂度。
• 只关注峰值 QPS，不关注数据增长、恢复时间和容量余量。
• 在生产直接改参数或加索引，没有观察窗口和回滚。
• 把“没有故障”误认为“没有风险”。

十五、最终毕业标准

如果能独立完成以下任务，就具备生产级 MySQL 工程能力：

1. 从业务访问模式推导表、索引、事务和归档方案。
2. 在 1 亿行级别的可控实验中定位并优化一条慢 SQL。
3. 解释 InnoDB 事务、锁、redo、undo 和 binlog 的协作关系。
4. 从备份恢复到任意时间点，并验证数据一致性。
5. 搭建主从或 MGR，完成故障切换和旧主隔离。
6. 设计监控、容量、安全和变更治理方案。
7. 用演练结果证明 RPO、RTO 和故障处理能力。
8. 在架构选择前，能说明为什么不是更简单的方案。

这条路线的终点不是“会管理一套 MySQL”，而是能在业务增长、故障、恢复和成本压力下，持续做出可验证的数据库工程决策。