前两天刚帮某业务方做完一次单库迁移把一台旧实例上 300G 左右的业务库从 MySQL 5.7 搬到新环境的 8.0 集群。整个过程没有引入额外工具就是标题里这套经典组合——mysqldump 导出、scp 传输、改名导入、权限处理。这篇就把这次迁移的完整 SOP 拆开讲透每个参数为什么这么选、每个步骤背后在防什么坑都会说明白。不管你是第一次做单库迁移的新手还是已经干过几次但总觉得差点意思的运维这篇文章应该都能帮到你。1. 为什么要用逻辑迁移这套组合拳1.1 逻辑迁移和物理迁移怎么选数据库迁移这件事业内大体分两条路物理迁移和逻辑迁移。物理迁移的代表是直接拷贝数据文件常用工具是 Percona XtraBackup或者干脆冷备停机把整个 data 目录打包过去。物理迁移的优点非常明显——快因为它做的是文件级拷贝本质上不关心表里存了什么几十 GB 的数据跑起来就是磁盘 IO 的速度。缺点也同样明显依赖底层存储引擎格式跨版本、跨平台、跨小版本升级都可能踩兼容性的雷而且通常只能整实例迁移想单独挑一个库出来很难。逻辑迁移的代表就是 mysqldump它把数据转成 SQL 语句文本在目标库重新执行一遍。速度确实慢300G 的库物理备份可能半小时完成逻辑导出加导入往往要几个小时甚至更久。但它的优势换个角度看完全是压倒性的跨版本友好从 5.6 导出的 SQL导入 8.0 通常问题不大反过来则要注意语法兼容跨平台友好Linux 导出的文件在 Windows 上照用可以部分导出想迁一个库就导一个库想过滤某些行也方便落地是文本可以用 sed、awk 等工具做二次加工比如改名、替换存储引擎结构完全重建顺带把碎片和膨胀的索引恢复一遍所以我的判断是如果是整实例、数据量大、停机窗口短的场景优先考虑物理备份如果只是单库、几百 G 以内、有几个小时窗口mysqldump 这套组合拳依然是最稳妥、最透明的方案。这次迁移就是典型的第二种场景。1.2 单库迁移的特殊性停机窗口与一致性单库迁移和整实例迁移还有个本质区别整实例迁移通常意味着目标实例是空的迁移完成后应用连接串整个切过去而单库迁移往往是目标实例上已经跑着其他库你只是把其中一个库搬进去。这就带来两个额外问题一是目标实例的全局配置字符集、GTID 模式、sql_mode未必和源端一致导入时可能要临时适配二是库名可能冲突目标实例上已经有一个同名库了这时候改名导入就成了刚需。再就是停机窗口。逻辑迁移再怎么优化导出和导入都不可能瞬间完成应用侧必须有计划内停写的时间。实际操作中我一般把窗口拆成三段导出阶段应用正常读写用一致性快照兜底、传输阶段应用正常读写不影响、导入阶段应用停写保证目标库数据追平源库。只有导入阶段才是真正的停机窗口所以导出和传输都可以提前完成把停机时间压缩到最小。1.3 整体流程一览先把这次的完整流程画一张流程图在脑子里环境盘点确认源库和目标库版本、字符集、磁盘空间、账号依赖mysqldump 导出带一致性快照参数导出结构、数据、存储过程、触发器、事件scp 传输从源服务器传到目标服务器校验 md5改名导入按需改写库名导入目标实例必要时调整参数权限处理迁移账号和授权验证连接数据验证表数量、行数、抽样数据、业务冒烟切换改应用连接串或 DNS观察一段时间后清理源库下面逐段展开。2. 动手之前环境盘点和参数决策2.1 版本差异与字符集检查很多人一上来就敲 mysqldump这是大忌。迁移前不盘点环境后面八成要翻车。这次源库是 5.7目标库是 8.0两者差异比想象中大得多先说几个最常见的坑。第一是默认字符集。5.7 默认 latin1很多老库建表时没显式指定字符集实际就是 latin1。8.0 默认字符集改成了 utf8mb4如果直接把老库的 SQL 往新库灌一部分表可能被建成了 utf8mb4但表里存的 latin1 字节序列没有重新编码导入后就是乱码。正确做法是导出前逐库、逐表确认字符集必要时在导出文件头部加SET NAMES声明在导入前用sed调整建表语句里的DEFAULT CHARSET。第二是 sql_mode。5.7 的默认 sql_mode 里有ONLY_FULL_GROUP_BY、STRICT_TRANS_TABLES之类8.0 默认更严格还加了NO_ZERO_IN_DATE、NO_ZERO_DATE等。如果老业务里有往日期字段存0000-00-00的情况导入时很可能直接报错。我的习惯是导入前先查两边SELECT sql_mode;如果目标库严格得多要么先和业务方确认数据清洗方案要么导入时临时放宽导入完成后再恢复严格模式。第三是密码插件。5.7 默认mysql_native_password8.0 默认caching_sha2_password。权限迁移时如果直接把旧账号的哈希搬过来或者用老客户端连接新库都会出现认证失败。这个在第六章权限处理里详细说。2.2 磁盘、网络、工具链评估盘点完版本接着算资源账。核心是三块源库导出文件的落盘空间、传输带宽的耗时、目标库导入时的临时空间。导出文件大小估算没有精确公式但可以拍脑袋给个范围一个以字符串和数值为主的库导出 SQL 文件大概是数据文件体积的 0.3~0.5 倍如果里面大量是 TEXT/BLOB 或者 JSON比例会高一些可能到 0.8 倍。最稳的办法是先在源库跑SELECT table_schema, ROUND(SUM(data_length index_length) / 1024 / 1024 / 1024, 2) AS size_gb FROM information_schema.tables GROUP BY table_schema;拿到库的物理大小再按 0.5 倍预留导出文件空间。网络传输时间也要提前算。假设导出文件 150G两边带宽 1Gbps理论上限是 150G × 8 / 1Gbps ≈ 1200 秒也就是 20 分钟但实际走公网或专线很难跑满一般按理论值的 30%~50% 估就是 40~60 分钟。如果这个时间不可接受就得考虑用压缩传输或者换物理备份方案。工具链上还有个小细节mysqldump 用哪个版本我的建议是尽量用目标实例同版本或更高版本的客户端工具导出。因为 mysqldump 生成的 SQL 是向下兼容的用 8.0 的客户端导出 5.7 的数据通常没问题反过来用 5.7 的客户端导出后往 8.0 灌虽然大多数情况也没事但遇到 8.0 新增的语法特性就抓瞎了。2.3 对象与权限盘点这一节容易被忽略但恰恰是返工率最高的地方。导库之前先确认源库里都有哪些数据库对象SELECT COUNT(*) FROM information_schema.tables WHERE table_schema 你的库名; SELECT COUNT(*) FROM information_schema.routines WHERE routine_schema 你的库名; SELECT COUNT(*) FROM information_schema.triggers WHERE trigger_schema 你的库名; SELECT COUNT(*) FROM information_schema.events WHERE event_schema 你的库名; SELECT COUNT(*) FROM information_schema.views WHERE table_schema 你的库名;如果存储过程、触发器、事件的数量不是零导出命令里就必须带上--routines、--triggers、--events这三个参数否则导出的文件里只有表结构和数据应用一上线直接报存储过程不存在。账号权限盘点同样重要。查一下都有哪些账号能访问这个库SELECT user, host FROM mysql.db WHERE db 你的库名;更好用的是SHOW GRANTS可以列出每个账号的具体权限。把结果记录下来后面迁移权限时直接照着抄。3. mysqldump 导出每个参数背后的坑3.1 一条完整导出命令的拆解这次我用的是下面这条命令几乎囊括了单库逻辑迁移需要关注的所有点mysqldump \ -u root -p \ --single-transaction \ --routines \ --triggers \ --events \ --hex-blob \ --set-gtid-purgedOFF \ --master-data2 \ --default-character-setutf8mb4 \ --databases order_db \ order_db_20260317.sql 2 order_db_export.err先说明一下输出重定向SQL 文件走标准输出mysqldump 的日志和报错走标准错误我用2单独存了一份方便排查问题。这个习惯帮我省过不少事导出到一半报错的时候不用瞎猜直接看 err 文件里最后几行。逐参数来说。--single-transaction是最重要的一个。它让 InnoDB 在导出时基于一致性快照读到的数据是导出开始那一刻的视图全程不加表锁业务可以继续写。注意两个前提一是表必须是 InnoDBMyISAM 表不受这个参数保护依然会锁表二是导出过程中如果有人执行 DDL比如 ALTER TABLE可能导致Table definition has changed的报错。所以导出前最好和业务方确认这段窗口内不要有结构变更。--routines、--triggers、--events上面说过是导出存储过程、触发器、事件对象的关键。不带的后果是导入后应用大面积报错而且很难排查。--hex-blob把 BLOB 和二进制字段以十六进制字面量导出避免二进制数据在转义和传输过程中被破坏。如果你的表里有图片、文件流、加密串这类字段这个参数必须加。--set-gtid-purgedOFF这个参数要看场景。源库如果开启了 GTIDmysqldump 默认会在导出文件里写入SET GLOBAL.GTID_PURGED...这样的语句。如果目标实例也有 GTID导入时会尝试清空目标 GTID 集合不仅报错还有可能污染目标实例的复制状态。单库迁移最稳妥的做法是显式设为 OFF把 GTID 信息处理交给复制架构去解决导出文件里只保留纯数据语句。--master-data2会在导出文件里以注释形式记录当时的 binlog 文件名和位置格式类似-- CHANGE MASTER TO MASTER_LOG_FILEmysql-bin.000123, MASTER_LOG_POS456789。虽然这次迁移用不到搭建主从但记录下位置信息万一迁移过程中需要追增量这就是唯一的线索。设为 2 是因为它只写入注释不会真的执行 CHANGE MASTER 语句安全性更好。--default-character-setutf8mb4指定导出时客户端连接的字符集。注意这里有个细节它只影响导出的连接字符集不会帮你把表的字符集改掉。也就是说源库如果是 latin1 的表导出文件里依然会是 latin1 的建表语句和原始字节这个参数保证的是传输链路不会额外引入乱码。最后--databases order_db和直接order_db有区别带--databases会在导出文件里包含CREATE DATABASE和USE语句适合单库整体迁移不带则只导出表结构数据适合后续要手动指定目标库名的情况。这次因为要做改名后面我会讲到怎么处理这个差异。3.2 事务一致性与锁的关系--single-transaction的原理是开启一个可重复读级别的事务通过 MVCC 拿到一致性快照。这个设计很巧妙但对大库有个实际的副作用导出过程中 undo log 会不断膨胀因为 InnoDB 需要保留快照对应的历史版本。如果库的写入压力很大导出一两个小时undo 表空间可能吃掉大量磁盘。解决思路有两个一是错峰导出选择业务低峰期执行二是提前检查 undo 表空间的剩余空间。执行前可以用SHOW ENGINE INNODB STATUS\G看 history list length如果这个值很大说明旧的未清理版本本来就多再叠加导出的快照风险会更高。另外有 MyISAM 表的话--single-transaction不生效导出时会自动对这些表加读锁。单库迁移通常不建议混用存储引擎如果确实有提前和业务方确认是否可以接受短暂的只读窗口。3.3 容易被漏掉的对象存储过程、触发器、事件再强调一次--routines、--triggers、--events这三个参数在默认情况下都是不导出的。很多人第一次做迁移导完数据、验证完行数高高兴兴切换连接串结果应用调用存储过程时直接报PROCEDURE db_name.proc_name does not exist。这种问题最容易在业务晨高峰爆发非常被动。还有一点导出的存储过程和触发器中如果带有DEFINER信息即创建者账号导入到目标库时要求该账号必须存在否则报ERROR 1449 (HY000): The user specified as a definer does not exist。这是权限迁移和结构迁移强耦合的地方我们会在第六章处理。3.4 GTID 与 binlog 位置的取舍--set-gtid-purgedOFF已经保证了导出文件不携带 GTID 信息。但迁移完如果要做主从复制或者要追增量就需要用到--master-data2记录的 binlog 位置。实际操作时我会把这个位置信息单独抄到运维文档里格式类似源实例 binlog 位置mysql-bin.000123:456789 导出时间2026-03-17 02:00:00 迁移后目标库主键最大 IDxxx这份记录在迁移验证、回滚判断时都非常有用。尤其是回滚场景——如果目标库数据有问题要回退你需要知道源库导出后产生了多少增量才能判断是重新导还是补增量。4. scp 传输别急着拷文件4.1 传输命令与压缩策略导出完成后接下来是把 SQL 文件从源服务器传到目标服务器。最直接的工具就是 scpscp order_db_20260317.sql root目标服务器IP:/data/migration/操作本身简单但有几个点值得说道。第一压缩策略。如果 SQL 文件是纯文本压缩率通常很高10G 的文件 gzip 后可能只有 2~3G。所以导出时可以直接加管道mysqldump ... | gzip order_db_20260317.sql.gz这样传输的是压缩包能大幅缩短传输时间。注意如果已经 gzip 了scp 就别再加-C压缩参数否则 CPU 做两次压缩纯属浪费。反过来如果没压缩且网络带宽有限scp -C是值得开的。第二端口和非标准路径。很多生产环境 sshd 端口不是 22用-P指定。建议用密钥登录而不是密码大文件传输时密码认证如果中断重新输密码也麻烦。scp 不支持断点续传传一半断网就前功尽弃所以我会配合 tmux 或 nohup 避免终端关闭导致传输中断。真要追求断点续传可以用 rsync 替代rsync -avP --partial order_db_20260317.sql.gz root目标服务器IP:/data/migration/--partial保留已传输的部分-P显示进度并支持断点续传大文件场景比 scp 稳得多。4.2 完整性校验的三重保险传输完成的瞬间先别急着解压导入必须做完整性校验。我的习惯是三道检查第一道文件大小对比。ls -l看源端和目标端的文件字节数是否一致这个最直观但不足以证明内容没坏。第二道md5 校验。在源端执行md5sum order_db_20260317.sql.gz记下哈希值到目标端同样执行md5sum两个值必须完全一致。这一步能防绝大多数传输损坏。第三道解压完整性。gzip 文件可以先跑gzip -t order_db_20260317.sql.gz它只检查文件能否完整解压不实际解压内容。如果 gzip 报错说明压缩包已经损坏重新传。三道都过才允许进入导入阶段。这一步省不了我见过有人传完文件直接导入导到一半报错排查半天发现是文件在传输中损坏了白白浪费几个小时。4.3 大文件传输的耐心与监控传输几十 G 的文件时间动辄半小时以上。这期间不要干等着我一般开一个独立的终端窗口用watch或者直接看 rsync 的进度输出。scp 自带进度条但如果终端断了就什么都没了所以务必用 nohup 或者 tmux 包一层。还有一个容易被忽略的点源服务器和目标服务器之间的网络如果是专线通常没问题如果走公网要考虑防火墙对长连接的超时设置。之前遇到过传输到一半连接被静默断开的情况排查发现是中间防火墙把长时间空闲的连接踢了。解决办法是 ssh 配置里加ServerAliveInterval 60每 60 秒发一个保活包防止空闲连接被清理。5. 改名导入一种低风险的落地策略5.1 为什么需要改名改名导入这四个字是这个 SOP 里最有价值的部分。常规迁移是源库什么名目标库还叫什么名直接导入完事。但实际工作中经常会遇到目标库名和源库名不一致的情况常见的有三类目标实例上已经存在同名库不能直接覆盖业务方要求新环境用新的库名做区分比如后缀加_new想通过影子导入把源库导入到一个临时库名验证没问题后再切换到正式库名降低风险第三种用法特别实用。比如源库叫order_db我导入目标实例时先建成order_db_tmp跑完验证后再通过改名正式落地。这相当于给迁移加了一层预演机制即使导入过程中发现问题也不会污染正式环境。5.2 改名导入的正确姿势改名听起来简单做起来有讲究。最初的惯性思路是导出后拿 sed 把 SQL 里的库名全部替换sed s/order_db/order_db_tmp/g order_db_20260317.sql order_db_tmp.sql这个方案在小库、结构简单的场景能用但隐患很大如果表名、列名、注释、存储过程体里恰好包含order_db这段字符串会被误替换导入后数据或代码逻辑就错了。所以对于生产库我不推荐 sed 无脑替换。更稳的做法是分两步走。第一步把源库按不包含库名的方式导出也就是前面说的不用--databases参数mysqldump \ -u root -p \ --single-transaction \ --routines \ --triggers \ --events \ --hex-blob \ --set-gtid-purgedOFF \ --default-character-setutf8mb4 \ order_db \ order_db_20260317.sql 2 order_db_export.err注意这里--databases去掉了导出文件里只有建表语句和 INSERT 语句不包含CREATE DATABASE。第二步在目标实例上先手动建一个目标库想叫什么叫什么然后执行导入CREATE DATABASE order_db_tmp CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;导入时用mysql客户端显式指定库名mysql -u root -p -h 目标实例IP \ --default-character-setutf8mb4 \ order_db_tmp order_db_20260317.sql这样库名从头到尾由你自己控制完全不碰文件内容彻底避免 sed 误替换的问题。如果后续真的需要把order_db_tmp改成正式名用一条RENAME TABLE语句链或者重建库的方式都能做到。5.3 导入参数与加速技巧导入阶段是整个迁移中最耗时的一环300G 的库导入两三个小时很正常。为了提速行业内常用的手段是调整目标实例的会话参数但这属于有代价的加速要说清楚利弊。SET GLOBAL innodb_flush_log_at_trx_commit 2; SET GLOBAL sync_binlog 0; SET GLOBAL foreign_key_checks 0; SET GLOBAL unique_checks 0;innodb_flush_log_at_trx_commit 2每次事务提交只写 OS 缓存不强制刷盘减少磁盘同步次数。代价是如果数据库进程异常崩溃可能丢失最近 1~2 秒的事务。sync_binlog 0关闭 binlog 的强制刷盘同样提升写入性能。代价是异常时 binlog 可能缺最近几条。foreign_key_checks 0导入时跳过外键约束检查避免因为表的插入顺序触发外键校验而拖慢速度。前提是你的表结构中有外键且导入完成后要记得恢复为 1然后手动做一次外键约束校验。unique_checks 0导入时跳过唯一索引的重复检查对导入速度提升明显。代价是如果源数据本身有重复值导入完成后才发现。这几个参数共同点是把安全阀暂时拧松换导入速度。项目管理上必须接受这个风险并且导入完成后立即恢复默认值。顺便说一句SET GLOBAL是实例级别的只对新建会话生效导入会话要重新连接或者同时SET SESSION才能确保当前导入进程也吃到这些参数。还要记得把max_allowed_packet调大。默认 4M 或 64M 可能不够大字段的插入语句使用我一般导入前在目标实例执行SET GLOBAL max_allowed_packet 1G;避免出现Got a packet bigger than max_allowed_packet bytes的报错。5.4 导入过程中的进度监控导入一旦开始你面对的就是一个黑盒不知道导到哪了不知道还要多久。我的做法是另开一个终端连到目标实例不停刷信息SELECT * FROM information_schema.processlist WHERE command Query AND info LIKE INSERT INTO %\G;这个 SQL 能看到当前正在执行的 INSERT 语句目标表名。如果你知道表按数据量排序是哪些就能推算进度。更粗粒度的监控是看目标库已经有多少张表被创建出来SELECT COUNT(*) FROM information_schema.tables WHERE table_schema order_db_tmp;建表语句是一批批执行的表数量增长基本可以对应到导入阶段。还有个经验值导入单表数据的耗时和数据量基本成正比数据量最大的前几个表导入完成整个导入也就进入尾声了。6. 权限处理账号跟着库走还是单独梳理6.1 账号盘点与授权导出数据导完了库名对了业务连不上等于白干。权限处理是迁移中最后一道决定成败的工序。先说账号迁移的完整套路。第一步在源实例上找出所有和这个库相关的账号。最简单的方式是看mysql.db表同时配合应用配置里的连接信息SELECT DISTINCT user, host FROM mysql.db WHERE db order_db;第二步逐个导出账号的授权信息SHOW GRANTS FOR app_user%;结果类似GRANT SELECT, INSERT, UPDATE, DELETE ON order_db.* TO app_user% GRANT EXECUTE ON PROCEDURE order_db.proc_xxx TO app_user%把这些输出完整记录下来。注意SHOW GRANTS不包含密码明文所以密码信息要另外想办法。第三步在目标实例创建账号并重新授权。密码的处理有两个思路一是让业务方提供新的密码在目标端设置这更符合安全规范二是如果要求密码保持一致可以通过查询源实例的mysql.user表拿到加密后的哈希串在目标端用IDENTIFIED WITH mysql_native_password AS 哈希串直接指定。第二种方式在跨大版本时风险比较高因为 5.7 的哈希算法/插件格式和 8.0 不一定兼容所以跨版本迁移我建议走第一种思路让业务方重新设置密码。目标端的授权命令示例CREATE USER app_user% IDENTIFIED BY 新密码; GRANT SELECT, INSERT, UPDATE, DELETE ON order_db.* TO app_user%; GRANT EXECUTE ON PROCEDURE order_db.proc_xxx TO app_user%; FLUSH PRIVILEGES;6.2 跨版本权限迁移的兼容性问题如果源库是 5.7、目标库是 8.0权限迁移里最常见的两个坑一是默认认证插件。8.0 默认caching_sha2_password而老的 JDBC 驱动如果版本太旧只支持mysql_native_password连接时直接报Authentication plugin caching_sha2_password cannot be loaded。解决办法CREATE USER app_user% IDENTIFIED WITH mysql_native_password BY 新密码;这样账号认证方式兼容老客户端但要注意 8.0 里mysql_native_password插件虽然还在官方已经标记为废弃能不用就不用建议同步让业务方升级驱动。二是授权粒度变化。8.0 对部分权限的划分更细比如 5.7 里的PROXY、SHOW_ROUTINE这类权限定义有调整。迁移后最好逐账号验证一次实际能执行的 SQL 类型不要想当然认为授权语句执行成功就万事大吉。6.3 权限验证清单账号全部建好后我会按下面的清单逐项验证用该账号从应用所在机器尝试连接目标实例mysql -u app_user -p -h 目标实例IP -P 端口执行SHOW DATABASES;确认只能看到授权的库对每个关键表做一次 SELECT 和一次 INSERT 测试插入后回滚或删除调用关键存储过程确认EXECUTE权限生效确认识别 DEFINER 的账号存在否则存储过程和触发器会报 definer 不存在的错误权限这件事验证做充分了切库后基本不会出幺蛾子验证偷懒出了问题往往就是连环的排起来特别费劲。7. 验证清单与常见问题排查7.1 数据一致性验证导入完成后验证环节必须做到位。我的验证分四层。第一层对象数量对比。在源库和目标库分别执行SELECT COUNT(*) FROM information_schema.tables WHERE table_schema order_db; SELECT COUNT(*) FROM information_schema.routines WHERE routine_schema order_db; SELECT COUNT(*) FROM information_schema.triggers WHERE trigger_schema order_db; SELECT COUNT(*) FROM information_schema.events WHERE event_schema order_db; SELECT COUNT(*) FROM information_schema.views WHERE table_schema order_db;两边数字必须完全一致。这一步用来发现导出的对象是否齐全。第二层表行数对比。逐个表执行SELECT COUNT(*) FROM 表名源库和目标库逐个对比。大表的 COUNT 在 5.7 下很慢可以用 information_schema 的TABLE_ROWS先粗筛一遍再对大表用抽样条件验证比如取MAX(id)、MIN(id)、最新一条记录的时间戳等。第三层抽样数据对比。选几个关键业务表取几条最新插入的数据逐字段对比内容。这一步最能发现字符集或者类型转换导致的隐性数据损坏。第四层业务冒烟。让业务方在目标环境跑一遍核心链路包括读写、调用存储过程、触发器等。这一步通常在权限验证完后进行相当于从应用视角做最终确认。7.2 常见报错速查表把这次迁移过程中遇到过的、以及同事在其他项目遇到的典型报错整理成一张表报错信息原因分析处理办法ERROR 1418 (HY000): This function has none of DETERMINISTIC...存储过程导入时 binlog 函数安全检查拦截在目标实例执行SET GLOBAL log_bin_trust_function_creators 1;导入完成后恢复ERROR 1449: The user specified as a definer...DEFINER 指定的账号不存在先迁移相应账号或修改存储过程的 DEFINERERROR 2006: MySQL server has gone away单条 SQL 超过 max_allowed_packet调大目标实例max_allowed_packetERROR 1227: Access denied; you need (at least one of) SUPER privilege8.0 导入时触发器/事件涉及 SUPER 权限受限确认账号有 SUPER 权限或把相关对象的 DEFINER 改成管理员账号字符集乱码源表和目标表字符集不一致逐表检查SHOW CREATE TABLE确认DEFAULT CHARSETERROR 3554: Access to system table mysql.user is rejected直接操作 mysql.user 表被拒绝改用 CREATE USER / ALTER USER、GRANT 语句导入速度异常缓慢目标库是主库且有大量从库写入复制压力大临时暂停部分从库复制或接受慢速并延长窗口ERROR 1044: Access denied for user root% to database连接账号权限不足改用高权限账号导入或按最小授权原则分账号操作每一条背后都是真实踩过的坑导入前把这张表过一遍能省下大量排错时间。7.3 回滚与收尾迁移不是导完就结束收尾动作同样关键。核心原则是源库在业务稳定运行观察期内不能动。我一般会留一个观察窗口至少跑满一个业务周期比如一天让业务方确认目标库无异常后再清理源库。观察期内建议执行以下动作保留源库和导出文件磁盘空间允许的情况下全部留着每天对比一次源库和目标库的关键数据表行数确认没有偏差监控目标实例的慢查询、报错日志看是否有兼容性导致的异常如果业务方决定长期用目标库再安排老实例的数据清理和下线流程回滚触发条件也很明确业务冒烟或观察期内出现目标库不可恢复的数据问题则把应用连接串切回源库目标库暂时保留但停止写入等根因分析完成后再决定下一步。8. 一些实际操作中的体会最后聊几点这次迁移下来感触最深的东西不算是完整的章节但比任何官方文档都有用。第一SOP 一定要带日期版本号。这次标题里的_20260317其实就是 SOP 的版本日期。数据库运维最容易出现上次怎么干的来着的尴尬把每次迁移的命令、参数、对象清单、账号列表、验证结果全部沉淀到一个文档里下次直接照抄能省一半时间。我自己的习惯是每个项目一份迁移文档命名格式就是迁移SOP_库名_日期日期一变版本就变方便回溯。第二导出参数宁可多带不要少带。--routines、--triggers、--events这种参数带上最多是多几秒执行时间不带就是上线后的连环故障。同样的道理--hex-blob虽然增加了导出文件体积但它把二进制数据处理的风险降到了最低。第三权限迁移永远比数据迁移更容易出问题。这是很多做过迁移的人共同的痛点。数据导错、行数不对验证阶段就能发现权限漏了、密码插件不兼容往往是应用切过去才爆雷而且爆雷时正是业务高峰期。所以权限验证一定要前置最好在正式切换前就完成一轮完整的应用侧连接测试。第四大文件传输过程中人不能完全撒手。scp 或者 rsync 跑着的时候隔一段时间看一眼进度和网络状态发现问题早处理比传输结束后发现文件损坏再重传要省事得多。这套组合拳没有花哨的技巧每一步都是基础操作但把它们按正确的顺序、用正确的参数串起来就能稳定地完成一次高风险的数据库迁移。希望这篇 SOP 能帮你少踩几个坑也让下次迁库的时候心里更有底。