MySQL 云数据库迁移演练：如何把停机窗口压到可控范围

这篇讨论想解决一个很具体的问题：MySQL（关系型数据库）从自建环境迁到云数据库时，如何把停机窗口从“拍脑袋估 30 分钟”变成一组能演练、能验收、能回滚的指标。很多站长迁库失败，不是因为 mysqldump 不会用，而是没有提前测导出速度、导入速度、增量差异、应用连接切换和回滚边界。下面按 WHT 社区常见中小站点场景，把一次迁移拆成可验证的演练流程。若你想先看同类迁站和主机选型思路，可以先参考 香港云服务器与传统主机的差异 和 中小企业云服务器选型思路，再回来看数据库迁移窗口通常会更容易对上号。

先说明边界：本文不讨论大型金融级双活，也不把云数据库包装成万能方案。这里假设业务库在 5GB-80GB 之间，站点可接受 10-60 分钟维护窗口，应用部署在 VPS（虚拟专用服务器）、独服（独立服务器）或云服务器（弹性计算服务器）上，目标是把数据库从单机自维护迁到托管数据库服务，同时保留明确回滚路径。

先看结论：迁移成败取决于 6 个数字

如果只让我看一页迁移计划，我不会先看“用了什么工具”，而会先看 6 个数字：全量导出耗时、全量导入耗时、最终停写耗时、增量追平耗时、校验耗时、回滚恢复耗时。只要这 6 个数字来自真实演练，停机窗口就有讨论基础；如果都是估算，上线当晚很容易拖成事故。

一个比较稳的演练记录可以这样写：源库 18GB，最大订单表 620 万行，测试导出 14 分钟，目标端导入 23 分钟，最后一次增量同步 4 分钟，关键表抽样校验 6 分钟，应用连接串切换和缓存清理 3 分钟。按这个结果，正式窗口不应写 30 分钟，而应预留 50-60 分钟，并把 35 分钟设为回滚评估点。

迁移前基线：不要只看数据库总大小

数据库总大小只能说明磁盘占用，不能直接说明迁移风险。真正影响窗口的是最大单表、索引体积、写入峰值、外键与触发器数量。比如总库 30GB，但 24GB 都在一张访问日志表里，业务表实际只有 6GB；这种情况下可以先归档日志表，再迁核心表。反过来，总库只有 8GB，但订单、支付、积分表持续写入，停写窗口就不能随意压缩。

迁移前建议至少跑一次结构盘点，把结果保存到变更单里：

SELECT VERSION();
SELECT table_schema,
       table_name,
       table_rows,
       ROUND((data_length + index_length) / 1024 / 1024, 2) AS size_mb
FROM information_schema.tables
WHERE table_schema NOT IN ('mysql','information_schema','performance_schema','sys')
ORDER BY size_mb DESC
LIMIT 20;
SHOW VARIABLES LIKE 'character_set_database';
SHOW VARIABLES LIKE 'collation_database';

这里要特别留意字符集和排序规则。旧站常见 latin1、utf8、utf8mb4 混用，导入目标端后可能出现 emoji 丢失、中文排序变化或唯一索引冲突。若站点同时在做程序迁移，可以参考 Linux I/O 瓶颈排查工具，把应用文件、附件、数据库三条线分开验收，避免数据库问题被应用缓存掩盖。SSL（安全传输协议）和证书链也要一起核对，避免迁移后浏览器报错。

停机窗口怎么估：把全量和最终切换分开算

不少人把“导出 + 导入 + 改配置”全部算进停机窗口，这会把窗口放大到不可接受。更实际的做法是提前完成全量导入，让源库继续对外服务；正式窗口只做停写、增量追平、校验和连接切换。这样 18GB 数据库不一定要停 40 分钟，可能只需要停最后 8-15 分钟。

全量阶段可以使用 mysqldump，但要注意一致性参数。对于 InnoDB 表，–single-transaction 能在不锁全库的情况下获得一致快照；如果混有 MyISAM 表，就要单独评估锁表影响。示例命令如下：

mysqldump -h SOURCE_HOST -u USER -p \
  --single-transaction \
  --routines --triggers --events \
  --default-character-set=utf8mb4 \
  --databases app_db > app_db_full.sql
mysql -h TARGET_HOST -u USER -p app_db < app_db_full.sql

演练时要记录实际吞吐，而不是只写“已导出”。例如导出文件 12GB，用时 16 分钟，平均 12.8MB/s；导入用时 31 分钟，平均 6.6MB/s。如果正式库涨到 20GB，导入可能接近 50 分钟。这个数字能直接决定是否需要压缩、并行导入、物理备份或迁移服务。对中小企业来说，迁移前也可以参考 云服务器上线检查清单，确认应用端和数据库端的 CPU（中央处理器）、磁盘 I/O（输入输出）与网络延迟是否匹配。

增量追平：窗口能不能压缩，关键看写入控制

全量导入完成后，源库仍会继续产生新订单、新评论、新会员记录。最终切换前必须处理这段差异。小站可以进入维护模式后再做最后一次增量导出；写入频繁的站点则应提前启用 binlog（二进制日志），记录全量备份点位，用复制或增量回放把目标库追到接近实时。

不管用哪种方法，都要把切换动作拆细：

• 停写入口：维护页、后台任务、支付回调和队列消费者都要暂停，不能只停前台 Web。
• 记录点位：保存 SHOW MASTER STATUS 的 File 与 Position，便于判断增量是否追平。
• 追平差异：最后一轮同步后，对订单、用户、支付、内容表分别记录行数。
• 切换连接：统一修改 .env、config.php、定时任务配置和队列配置，避免一半写新库、一半写旧库。
• 恢复写入：先放开后台测试账号，再恢复公开入口，观察 10-15 分钟。

这里最容易漏的是后台任务。很多电商站把订单同步、库存扣减、邮件发送放在 crontab（定时任务表）或队列里。前台维护页打开后，这些任务仍可能继续写旧库。正式演练时至少要检查一次任务清单，确认停写覆盖所有入口。如果业务跨境访问链路较长，还要关注 DNS（域名系统）缓存和应用到数据库的网络往返，相关思路可延伸阅读 服务器安全加固清单。

校验不是“能登录后台”，而是业务闭环通过

迁移后首页打开、后台能登录，只能证明连接串基本可用，不能证明数据完整。验收至少要覆盖结构一致、关键表数量一致、最近数据抽样一致、核心流程可跑通。对于内容站点，核心流程可能是登录、发布草稿、搜索文章、上传附件；对于订单站，则必须覆盖下单、支付回调、状态更新和退款标记。

我更倾向把校验分成两层：SQL（结构化查询语言）层和应用层。SQL（结构化查询语言）层看表数量、行数、最大时间戳、抽样主键；应用层看错误日志、慢查询和连接池。基础校验可以从下面几条开始：

SELECT COUNT(*) FROM orders;
SELECT MAX(created_at), MIN(created_at) FROM orders;
SELECT id, status, updated_at FROM orders ORDER BY id DESC LIMIT 50;
SHOW PROCESSLIST;
SHOW GLOBAL STATUS LIKE 'Threads_connected';

CHECKSUM TABLE 可以用于小表或低峰抽检，但不要在高峰期对大表无脑全跑。更可控的方法是抽 100-500 条最近订单或会员记录，比对主键、金额、状态、更新时间。上线后前 30 分钟，还要盯应用错误率、慢查询数量、数据库连接数和磁盘 I/O（输入输出）。如果连接池仍按本地库设置为 200，而目标端建议 80，就先收敛连接池，再判断是否扩容。

回滚预案：必须在迁移前写，不要上线后讨论

回滚不是失败，而是变更发布的安全带。迁移前就要写清楚触发条件：例如核心接口错误率超过 5% 持续 10 分钟、订单写入失败 3 次、支付回调无法落库、目标库延迟超过 60 秒且无法在 10 分钟内恢复。没有触发条件的回滚预案，到了现场只会变成争论。

更关键的是区分两种回滚：目标库没有接受新写入时，可以直接把连接串切回源库；目标库已经接受新订单或新用户时，就不能简单切回，否则新数据会丢。此时要么冻结业务做差异补写，要么保留目标库继续修复。对多数中小站点来说，最稳妥的策略是短窗口切换，先限制写入入口，确认 15-30 分钟稳定后再完全放开。

回滚文档至少包含旧连接串保存位置、配置回退命令、缓存清理命令、负责人和验证清单。密码不要明文贴到群聊，可以写在受控密码库或只记录变量名。Hostease 专区用户如果同时调整主机资源，可以把 服务器安全加固清单 作为参考，但数据库回滚仍应优先围绕数据一致性，而不是围绕服务器品牌或节点做决定。

结尾建议：先演练，再迁移正式库

如果你现在就要动生产库，我的建议很简单：先拿一份 1:1 备份，在测试环境完整演练一遍，按真实耗时倒推停机窗口，再决定正式迁移日期。不要把首次切换放在大促前、业务高峰期或没人值守的晚上。对于缺少专职 DBA（数据库管理员）的团队，可以先迁日志库、内容库或测试库，等流程跑顺后再动订单库、支付库这类核心资产。迁移前如果还想补一层应用侧准备，可以先看 WordPress 网站迁移实测流程，把数据库、程序文件和缓存刷新顺序先理顺。

最后再强调一次，云数据库不是目标，稳定可回退才是目标。你只要把基线、全量、增量、校验、回滚这五件事写实，迁移就不再是赌运气。如果你需要同时规划主机资源、备份策略和网站迁移流程，建议先把数据库迁移演练列入变更单，再决定是否上云数据库。这样做，通常比临时冲上去更稳。