MySQL数据库迁移前需要做哪些准备？一份实用检查清单

数据库迁移不是把数据导出、导入就结束了。真正容易出问题的环节，往往在迁移前：目标版本与应用不兼容、备份无法恢复、迁移窗口估算不足、字符集发生变化，或者切换后写入仍落在旧库。

这份清单适用于把 MySQL 搬到新服务器、新机房、云数据库，或升级 MySQL 大版本等常见场景。它重点讲迁移前需要确认什么、怎样验证，以及哪些做法有适用边界。示例以 Linux 命令行和 MySQL 客户端为主；执行前应先在测试环境验证，并按实际环境替换主机名、账号和库名。

一、先明确迁移目标和边界

“迁移 MySQL”可能指完全不同的工作。迁移方式、停机时间和验证方法，都取决于目标是什么。动手前先写清楚以下信息：

• 迁移对象：单实例、主从集群、分库分表的一部分，还是整个业务环境？是否包含存储过程、事件、触发器和视图？
• 源端与目标端：MySQL 的具体版本、发行版、操作系统、硬件或云规格。不要只写“5.7”或“8.0”，尽量记录完整版本号。
• 目标状态：是原样搬迁、升级版本、改变字符集，还是同时更改存储引擎、拓扑或云服务？每增加一项变更，风险和验证工作都会增加。
• 停机要求：可接受的只读或停写窗口多长？迁移期间能否冻结 DDL、定时任务和批处理？
• 恢复目标：发生故障时，最多能接受丢失多少数据（RPO），多长时间内必须恢复（RTO）？由谁决定继续迁移还是回退？
• 责任人：明确数据库、应用、网络、安全和业务验收人员，以及切换时的联系渠道。

常见迁移方式大致有三类：

• 逻辑导出与导入：通过 SQL 形式迁移表结构和数据，适合规模较小、需要跨平台或需要筛选对象的场景。迁移速度通常受导入执行 SQL 的能力影响，导出文件不等于可直接回滚的备份。
• 物理备份或存储级复制：复制数据文件或使用专门的物理备份工具，通常更适合数据量大且源、目标环境兼容的场景。必须确认工具与 MySQL 版本、存储引擎及操作方式相匹配；不能把运行中的数据目录随意复制到另一台机器后就假定一致可用。
• 复制追平后切换：先进行全量初始化，再通过复制或变更数据捕获同步增量，适合希望缩短停写窗口的迁移。它对复制配置、表结构一致性、复制延迟监控和切换流程要求更高，不是“开启复制就能无损切换”。

一次迁移尽量只解决一个主要问题。例如，先搬迁并保持版本和字符集不变，稳定后再升级版本，通常比“换平台、升大版本、改字符集、重构表结构”同时进行更容易排查。若必须合并变更，应为每一项单独设计测试和回退方案。

二、迁移前建立源库与目标库清单

不要仅根据配置文件推断数据库状态。先从运行中的实例采集信息，保存输出并注明采集时间。以下查询可以在 MySQL 客户端中执行：

SELECT VERSION() AS mysql_version,
       @@version_comment AS version_comment,
       @@hostname AS hostname,
       @@port AS port,
       @@server_id AS server_id;

SHOW VARIABLES
WHERE Variable_name IN (
  'character_set_server',
  'collation_server',
  'sql_mode',
  'time_zone',
  'system_time_zone',
  'lower_case_table_names',
  'max_allowed_packet',
  'log_bin',
  'binlog_format'
);

SELECT TABLE_SCHEMA,
       ENGINE,
       COUNT(*) AS table_count,
       ROUND(SUM(DATA_LENGTH + INDEX_LENGTH) / 1024 / 1024, 1) AS size_mb
FROM information_schema.TABLES
WHERE TABLE_SCHEMA NOT IN ('information_schema', 'mysql',
                           'performance_schema', 'sys')
GROUP BY TABLE_SCHEMA, ENGINE
ORDER BY size_mb DESC;

还要检查以下内容，并将结果与目标环境逐项比较：

• 各数据库、表、视图、触发器、存储过程、函数、事件和分区表清单。
• 每张表的存储引擎、字符集、排序规则、主键和索引；尤其留意没有主键的大表。
• 实例级参数、会话级参数、时区、SQL 模式，以及应用连接时会设置的会话变量。
• 账号、认证方式、授权范围、TLS 要求，以及依赖的主机名或网络白名单。
• 复制拓扑、二进制日志保留情况、备份计划、定时任务和外部监控。

源库和目标库的变量并非都必须相同。关键是识别差异，判断差异是否影响业务。例如，表名大小写行为与操作系统、MySQL 的 lower_case_table_names 设置有关；相关设置在不同环境中的可变性也有限制，不能把它当成普通运行参数在迁移后随意调整。应在目标实例初始化和导入前确认其实际行为。

三、验证版本、对象和应用兼容性

版本号相邻不代表完全兼容。尤其是大版本升级，要核对源端到目标端的官方升级路径、支持的平台和已移除或行为变化的功能。迁移到云数据库时，还要确认服务商是否限制特定参数、插件、账户操作或管理权限。

至少完成以下检查：

1. 对象检查：盘点依赖的引擎、插件、函数、事件调度器、触发器和存储过程。目标环境不支持的对象要提前替换或明确不迁移。
2. SQL 检查：在目标版本的测试实例导入结构，并执行核心读写、报表、批处理和事务流程。关注保留字变化、严格模式、默认值、隐式类型转换和排序规则差异。
3. 应用驱动检查：确认语言运行时、MySQL 驱动和连接池兼容目标版本。测试认证插件、TLS、连接超时、自动重连和连接池失效连接处理。
4. 字符集检查：分别检查数据库、表、列和连接字符集。不要只看 character_set_server 就认定所有字段采用同一字符集。
5. 容量检查：目标端磁盘需容纳数据、索引、临时文件、二进制日志和迁移期间的增长；内存、IOPS、连接数及复制带宽也应满足峰值需求。

对于使用 utf8mb4 的环境，尤其要检查索引定义、排序规则和旧版本遗留的列定义。升级或改变字符集可能影响索引长度、唯一性比较结果和排序行为。不能仅靠修改默认字符集就认为历史数据已经完成转换；应使用代表性数据测试转换结果，并检查可能出现的重复键或数据截断。

如果应用依赖时间类型，也要明确数据语义：MySQL 的 TIMESTAMP 会受到会话时区转换影响，而 DATETIME 不按会话时区自动转换。切换前用真实业务时区测试写入、查询、定时任务和跨夏令时场景，避免把“时间显示不同”误判成数据损坏，或反过来漏掉真实的时间偏差。

四、备份要能恢复，而不只是生成文件

迁移前必须有可验证的恢复点。备份策略应结合数据量、停机窗口和恢复目标选择，并记录备份时间、范围、加密方式、保存位置和保留期限。存放在与源库相同磁盘或相同故障域中的副本，不足以应对设备或机房故障。

下面是一个使用 mysqldump 导出单个数据库的示例。执行前创建有严格权限的凭据文件，例如 ~/.my.cnf：

[client]
user=backup_user
password=请替换为实际密码
host=127.0.0.1

chmod 600 ~/.my.cnf

mysqldump \
  --defaults-extra-file="$HOME/.my.cnf" \
  --databases appdb \
  --single-transaction \
  --quick \
  --routines \
  --events \
  --triggers \
  --hex-blob \
  --result-file=appdb.sql

注意，--defaults-extra-file 应放在该客户端程序参数列表靠前的位置。示例中的凭据文件仍是明文密码文件，必须限制文件权限、控制所在主机的访问，并避免将其提交到代码仓库或复制到不受控位置。生产环境可优先采用受管密钥、受限凭据机制或组织批准的秘密管理方案。

• --single-transaction 对 InnoDB 表可在一致性读事务中取得一致快照，通常不需要为导出过程锁定这些表。它不能为 MyISAM 等非事务表提供同样的一致性保证；导出期间执行并发 DDL 也可能造成问题。因此它不是“所有表、所有操作都无锁且一致”的承诺。
• --quick 逐行读取结果，适合减少客户端一次性缓存大结果集造成的内存压力；它不会减少数据库本身读取数据所需的时间。
• --routines 和 --events 用于包含存储程序与事件；触发器通常会随表结构导出，但显式写出 --triggers 有助于表达意图。还应检查账户和授权，不能假定数据库导出自动包含所有实例级账号配置。
• --hex-blob 将二进制列以十六进制形式输出，能避免某些二进制内容在文本转储中的表示问题；它不代表加密。
• 若需要跨多个非事务表获得一致的备份，通常要协调写入停顿或使用适合该环境的锁定、物理备份方案。具体做法取决于业务是否允许停写及工具能力。

将转储压缩时，可以把输出管道接到压缩程序，但应检查每个命令的退出状态，避免导出失败后仍留下看似完整的压缩文件。无论采用哪种备份方式，至少在独立测试实例完成一次恢复，并验证关键表、索引、程序对象及应用读写流程。恢复测试通过，才说明备份流程具备实际价值。

如果备份需要携带二进制日志位置或 GTID 信息以便建立复制，应使用与目标 MySQL 版本相符的客户端选项，并记录相应位点。不同版本、复制拓扑和是否启用 GTID 会影响参数选择；不能把某个固定参数组合当成所有环境通用的方案。

五、评估迁移时长与资源压力

数据文件大小不是迁移耗时的可靠估算值。逻辑导入需要执行建表和插入操作，索引重建、约束检查、磁盘写入、网络带宽和目标端规格都会影响速度；若还要同步增量，则要另外计算追平时间。

在正式窗口前，用与生产相近的数据量和硬件进行演练，至少测量：

• 导出、传输、解压、导入和索引创建分别耗时多久。
• 迁移期间源库的 CPU、磁盘 IO、锁等待、连接数和复制延迟变化。
• 目标端导入时的磁盘空间峰值、临时空间、日志增长及恢复耗时。
• 在业务峰值、批处理或备份任务并行时，迁移速度和应用延迟是否恶化。

按实测数据为正式窗口留出余量，并规划异常时的停止点。不要把“导入过程看起来还在运行”作为继续加压的理由。如果迁移会明显占用生产资源，应设置限速、错峰或分阶段迁移安排；具体限制方式依赖操作系统、工具和云平台能力，不能只通过调大某一个 MySQL 参数解决。

六、确认账号、网络与安全边界

迁移账号应遵循最小权限原则。备份账号只授予完成备份所需的读取及元数据权限；导入账号只在目标实例的必要范围内拥有建表、写入及创建所需对象的权限。不同版本和所选导出内容对权限要求可能不同，应依据官方文档和实际测试确认，避免直接给迁移账号长期保留管理员权限。

网络侧要检查源库到迁移执行机、迁移执行机到目标库的连通性、端口、防火墙、DNS、路由、白名单和 TLS 配置。不要为了临时迁移将数据库端口开放到公网。若必须跨网络传输，应使用经批准的加密通道，并确认备份文件落盘、临时目录和日志都受到保护。

提前创建目标端应用账号并验证授权。不要把业务流量直接切到使用管理员账号的连接配置上。检查密码轮换、证书有效期、主机名校验和连接字符串中的时区、字符集设置；同时避免在命令行参数、工单或执行日志中暴露密码。命令行密码参数可能出现在进程列表或历史记录中，因此不应把 -p实际密码 这样的写法放进脚本。

七、为数据一致性设计可执行的验证

迁移前先定义“迁移成功”的判定标准，而不是切换后再临时挑几张表查看。建议组合使用多种检查：

• 数据库、表、视图、触发器、程序对象和分区定义数量是否符合预期。
• 关键表的行数、主键范围、业务状态分布，以及关键金额、时间和状态字段的聚合结果是否一致。
• 抽样比对记录，覆盖边界值、非 ASCII 文本、二进制字段、NULL、极大或极小数值和近期变更数据。
• 应用侧执行代表性的查询、事务、写入、更新、删除和回滚流程，检查错误日志与业务告警。

行数相同不等于数据相同。对大型表，可以按主键范围或时间分段比对，控制查询对生产的影响；对高价值表，使用业务可解释的聚合校验或经过验证的校验工具。校验查询要考虑并发写入：如果源库和目标库校验期间仍在变化，结果可能无法直接比较。应明确一致性快照、停写时间或复制位点的比较口径。

注意字符集转换可能改变比较结果，浮点数也不适合用未经设计的精确字符串比较。对金额等业务关键值，应结合实际字段类型与业务规则设计校验。校验脚本必须先在测试数据上验证，不能把未经审查的全库长时间扫描直接安排在生产高峰。

八、切换和回退计划要在迁移前写好

一个可执行的切换计划应包含明确的负责人、时间点和判断条件。常见步骤如下：

1. 冻结或控制可能改变结构的操作，确认迁移版本、目标地址和备份恢复点。
2. 根据方案完成全量搬迁，并在需要时持续同步增量。
3. 切换前确认源库写入状态、复制延迟、待处理事务和最后同步位点。
4. 按计划停止旧库写入或进入只读维护窗口，确认目标端追平并完成最终校验。
5. 修改连接配置或路由，逐步恢复应用写入；检查错误率、连接数、慢查询和关键业务结果。
6. 保留旧库和必要日志，观察约定时间后再决定是否下线。

回退不是简单地把连接地址改回去。如果切换后目标库已经接受新写入，旧库通常没有这些数据；直接切回会产生数据分叉或丢失。迁移前必须明确回退触发条件，以及切换后数据如何同步回旧库、如何冻结写入、如何避免双写。若没有可验证的反向同步或数据修复方案，回退窗口应限制在目标库尚未接受业务写入的阶段，或者制定明确的前滚修复策略。

使用 DNS 切换时，提前降低 TTL 不等于所有客户端会立即更新；连接池和应用进程可能长期复用已有连接。配置变更还可能受缓存、代理和云平台路由影响。因此要通过实际客户端验证流量去向，而不是只检查 DNS 解析结果。

九、实用检查清单

• 范围：明确迁移对象、目标版本、迁移方式、停机窗口和验收标准。
• 盘点：记录版本、参数、对象、引擎、字符集、账号、复制关系和数据规模。
• 兼容性：在目标版本测试结构导入、应用驱动、SQL、认证、排序规则和时区行为。
• 容量：核算目标磁盘、临时空间、日志、内存、IOPS、网络和迁移期间增长。
• 备份：完成备份并在独立环境恢复，记录恢复耗时与数据校验结果。
• 安全：使用最小权限账号、加密传输和受控凭据；限制备份文件访问及保留期限。
• 演练：用代表性数据跑完整流程，测量耗时、资源压力、错误处理和应用验收。
• 切换：写明负责人、流量切换步骤、观察指标、停止条件及回退边界。
• 收尾：切换后验证监控、备份、告警、定时任务、权限和运维文档，并安排旧库下线审批。

十、容易导致事故的做法

• 只检查数据文件大小：忽略索引、日志、临时空间和导入时的额外消耗，导致目标磁盘耗尽。
• 默认所有表都是 InnoDB：在非事务表上误用 --single-transaction，却以为全库得到了一致快照。
• 只验证备份文件存在：未做恢复测试，直到故障时才发现文件损坏、权限不足或对象缺失。
• 同时变更多项基础条件：迁移、升级、字符集改造和应用改版一次完成，故障时无法快速定位原因。
• 只数行、不验业务：忽视字符转换、时区、默认值、触发器和事务行为变化。
• 把切换当作回退：新库开始写入后直接切回旧库，导致新数据丢失或两端状态分叉。
• 将秘密写进命令或脚本仓库：迁移结束后忘记清理凭据，扩大账号泄露风险。

迁移准备的核心不是找到一条“最快导入”的命令，而是把差异、数据一致性、恢复能力和切换边界提前验证清楚。先盘点，再演练；先证明备份能恢复，再安排生产窗口；先定义成功与回退条件，再让业务流量进入目标库。做到这些，迁移中的许多问题就能在测试阶段被发现，而不是在切换之后才变成生产事故。