mysqldump 导出时加 --single-transaction
防止锁表
线上 MySQL 迁移最常踩的坑是导出过程中业务卡死，尤其在大表或高并发场景下。
mysqldump默认不加事务控制，对 MyISAM 表会全程加读锁，InnoDB 表若没指定选项也会触发隐式锁。必须显式加上
--single-transaction，它利用 InnoDB 的 MVCC 特性，在导出开始时启动一个一致性快照，后续所有
SELECT都基于该快照，不影响写入。
实际命令示例：
mysqldump --single-transaction --routines --triggers --databases db1 db2 -u root -p > backup.sql
--routines和
--triggers要带上，否则存储过程、函数、触发器不会导出 避免用
--all-databases，它会把
mysql系统库也拉进来，新服务器权限体系不同，容易冲突 如果表里有大量 BLOB/TEXT 字段，建议额外加
--hex-blob，防止二进制数据被终端或传输层意外截断
导入前清空目标库要小心 FOREIGN_KEY_CHECKS
直接
DROP DATABASE再
CREATE最省事，但若只能复用旧库名且需保留部分结构（比如只换数据不换用户权限），就得手动清空。这时如果表间有外键，
TRUNCATE TABLE会失败，
DELETE FROM又慢还可能被锁。
标准做法是临时关掉外键检查：
SET FOREIGN_KEY_CHECKS = 0; source backup.sql; SET FOREIGN_KEY_CHECKS = 1;务必在
source执行前后成对设置，漏掉第二句会导致后续所有 DML 操作跳过外键校验，数据一致性风险极高 有些 dump 文件开头自带
SET FOREIGN_KEY_CHECKS=0，但结尾未必还原，不能依赖——自己手动包一层更可靠 如果目标 MySQL 版本比源低（比如从 8.0 迁到 5.7），dump 中的
JSON字段或新语法会报错，得加
--skip-definer和
--set-gtid-purged=OFF降级兼容
迁移后验证 information_schema.TABLES
行数是否一致
光看
SHOW TABLES或文件大小没用，真正要确认的是每张表记录数是否和源库一致。别用
COUNT(*)全表扫描——大表耗时太久，改查
information_schema.TABLES的
TABLE_ROWS字段即可，它是 InnoDB 的估算值，误差通常在 1% 以内，够迁移核对用。
快速对比脚本思路：
SELECT table_name, table_rows FROM information_schema.TABLES WHERE table_schema = 'db1' ORDER BY table_name;执行完导出和导入后，分别在源库和目标库跑这句，导出为 CSV 对比，比肉眼扫快得多
TABLE_ROWS对 MyISAM 是精确值，对 InnoDB 是估算值；若某张表误差超过 5%，说明可能漏数据或字符集转换出问题（比如源库 utf8mb4，目标库还是 utf8） 主从延迟或 binlog format 设置（如 ROW vs STATEMENT）也可能导致
TABLE_ROWS不一致，这种要单独查
SHOW MASTER STATUS和
SHOW SLAVE STATUS
用户权限和 mysql.user
表不能靠 mysqldump 同步
mysqldump默认不导出
mysql库，即使加了
--all-databases，5.7+ 版本也会跳过它。而用户账号、密码哈希、host 限制、权限粒度都存在
mysql.user表里，必须单独处理。
安全做法是用
mysqlpump（MySQL 5.7+）或手动导出权限：
mysqldump --no-create-info --no-data --compact mysql user db tables_priv -u root -p > users.sql导出后，目标库执行前先
FLUSH PRIVILEGES清缓存，再
source users.sql注意：MySQL 8.0 的密码哈希算法升级为
caching_sha2_password，如果目标库是 8.0 但客户端不支持，连接会失败，得在创建用户时显式指定
IDENTIFIED WITH mysql_native_password生产环境切忌用
GRANT ALL ON *.*复制权限，应按最小权限原则重配，尤其避免复制
SUPER或
REPLICATION CLIENT权限到普通应用账号 迁移最难的不是导出导入本身，而是那些看不见的依赖：字符集默认值、SQL mode、时区设置、半同步开关、甚至客户端连接池的 wait_timeout 配置。这些不一致往往在上线后几小时才暴露，比数据丢一半还难排查。
