mysqldump未加–single-transaction会导致全库只读锁；迁移到mysql 8.0时因tx_isolation变量废弃而报错；导入大文件需调优max_allowed_packet、wait_timeout并处理autocommit；视图、事件、权限等需额外参数导出，字符集须显式指定utf8mb4。
mysqldump 导出时没加 --single-transaction，线上库锁表了
导出大表或高并发业务库时，mysqldump 默认会执行 FLUSH TABLES WITH READ LOCK，导致整个库只读——这不是“慢”，是直接卡住写入。尤其在 MySQL 5.6+ 的 InnoDB 表上，完全没必要锁全库。
- 加
--single-transaction：利用 MVCC 快照，导出过程不锁表（仅要求引擎为 InnoDB） - 不加该参数又没用
--lock-tables=false：即使只导一张表，也会锁所有表（默认行为） - 如果混用了 MyISAM 表，
--single-transaction无效，必须配合--lock-tables=false+ 手动停写，否则导出不一致 - 示例命令：
mysqldump --single-transaction --routines --triggers -u root -p db_name > backup.sql
从 MySQL 5.7 迁移到 8.0，dump 文件导入失败报错 Unknown system variable 'tx_isolation'
MySQL 8.0 废弃了 tx_isolation 系统变量，改用 transaction_isolation，但老版本 mysqldump 生成的 SQL 里仍含 SET session tx_isolation = ...，导致 8.0 导入时报错。
- 根本原因不是 dump 工具版本低，而是
mysqldump会根据**目标服务端版本**（不是本机版本）决定是否写兼容语句——所以要在 8.0 服务器上运行mysqldump，或显式指定--set-gtid-purged=OFF和--compatible=mysql40（慎用，可能丢特性） - 更稳妥做法：用源库所在机器的
mysqldump（5.7），但加--skip-set-charset --no-tablespaces，并手动删掉 dump 文件头部的SET @@tx_isolation=...行 - 导入前检查：
head -20 backup.sql | grep tx_isolation，有就删
导入大 SQL 文件卡死、超时或中断，max_allowed_packet 不是唯一元凶
导入失败常被归咎于 max_allowed_packet，但它只是第一道门槛；真正卡住的往往是客户端连接超时、服务端 wait_timeout，或者 SQL 文件里隐含的 autocommit 关闭逻辑。
- 服务端调大：
SET GLOBAL max_allowed_packet = 512*1024*1024;（注意单位是字节） - 客户端也要设：mysql 命令行加
--max-allowed-packet=512M，否则客户端自己就截断了 - 关键但易忽略：
wait_timeout和interactive_timeout默认 28800 秒（8 小时），但大导入常因网络抖动或中间代理（如 ProxySQL）提前断连；建议导入前执行SET SESSION wait_timeout = 216000;（60 小时） - 如果 dump 文件含
SET autocommit = 0，且事务极大，可能撑爆 undo log；可先用sed -i 's/SET autocommit = 0;/SET autocommit = 1;/' backup.sql强制分段提交
迁移后发现视图、存储过程失效，--routines 和 --triggers 不够用
--routines 只导函数和存储过程，--triggers 只导触发器，但视图、事件、用户权限、字符集定义这些都得单独处理，漏一项就可能让应用查不到数据或权限报错。
- 视图必须加
--skip-triggers？不，视图本身是CREATE VIEW语句，只要没用到被删表就能导，但依赖表必须先存在；导出时加--skip-triggers是为了防止触发器干扰，不是视图必需 - 事件（Event）默认不导，要加
--events - 用户和权限需单独导：
mysqldump -u root -p --no-data --no-create-info --skip-triggers mysql user db event proc > grants.sql - 字符集问题最隐蔽：5.7 默认
utf8mb4，但 dump 文件若没带default CHARSET=utf8mb4，8.0 可能按utf8mb3解析；导出时强制加--default-character-set=utf8mb4
实际迁移时，最耗时间的往往不是 dump 或 restore，而是校验——表行数、checksum、主键连续性、外键约束是否重建成功。这些没法靠一个参数解决，得写脚本逐项比对。