S11-A02 · 部署与迁移：Docker 跑 MySQL、Flyway

适用读者：要上线数据库、或要改生产表结构的人。
前置：S11-B01。
覆盖旧文：2691(122) 2659(59) 484(37) = 218 点。
覆盖扩展：E-S11-021（迁移三件套）。
上一篇：S11-A01 · 引擎、主键与锁
下一篇：S11-A03 · MySQL → ES / 缓存一致性。

1. 一句话结论

"能跑起来"和"能安全变更"是两件事：容器解决前者，迁移工具解决后者。生产数据库的每一次结构变更都必须可回滚、可审计。

2. 为什么不建议 Docker 跑 MySQL（A-2691）

风险	说明
数据卷	容器重建/误删卷 = 数据丢失
IO 性能	存储驱动叠加（overlayfs）拖慢刷盘
内存/资源	容器限额与 buffer pool 冲突
运维习惯	备份/恢复脚本常假设物理机

判据："这是生产主库吗？" 是 → 物理机/云数据库；开发测试 → 容器完全够用。

开发用容器的正确姿势：

volumes:
  - ./data:/var/lib/mysql        # 数据必须落盘
  - ./conf/my.cnf:/etc/mysql/conf.d/my.cnf

3. 主从延迟怎么解（A-2659）

方案	说明
并行复制	多线程重放（8.0 默认 LOGICAL_CLOCK）
拆大事务	大事务是延迟主因
关键读走主库	写后立即读
半同步复制	保证至少一个从库收到

判据："业务能容忍读到旧数据吗？" 不能 → 关键路径强制主库（S08-A02）。

4. 迁移：Flyway 与三件套（E-S11-021、A-484）

-- V1__init.sql / V2__add_index.sql

工具	特点
Flyway	版本号命名、`schema_history` 记录、简单可靠
Liquibase	XML/YAML，功能更强、更重

迁移三件套：

① 向后兼容（先加列、后改代码、最后删旧列）
② 可回滚（每步都有 undo 脚本或兼容方案）
③ 可观测（迁移耗时、锁等待、失败告警）

"改列类型"为什么最危险：多数情况需要重建表（S11-B04 §4），大表会长时间锁/占用磁盘。

5. 变更检查单

#	检查项
1	是否在低峰期？预计耗时多久？
2	是否需要 Online DDL（`ALGORITHM=INPLACE`）或 gh-ost？
3	备份是否可用、恢复演练过吗？
4	回滚脚本写了吗？
5	从库延迟会不会被拖大？
6	应用兼容（新老代码同时跑）？

6. 五个误区

误区	真相
"容器跑 MySQL 很方便所以生产也用"	数据卷/IO/运维风险
"迁移就是执行 SQL"	要兼容、回滚、观测
"改列类型很快"	常需重建表
"有备份就安全"	没演练过的备份不算备份
"从库延迟只影响读"	也影响切流与备份

7. 自检（架构师版）

生产不建议 Docker 跑 MySQL 的四个理由？
主从延迟的四种缓解手段？
迁移三件套是什么？
为什么"改列类型"最危险？
变更检查单里哪两条最容易被跳过？

8. 下一篇

S11-A03 · MySQL → ES / 缓存一致性

部署讲完，最后一篇架构文：数据同步的三条路线与一致性边界。

本篇属于系列《S11 · 数据库与 SQL》。旧文来源：A-2691/2659/484；扩展点 E-S11-021。