mysqlpump 备份卡住或报错因默认启用并行导出与mdl锁，遇长事务、低权限（需select/lock tables/show view/trigger）或版本＜5.7.8即失败；应使用--single-transaction、--default-parallelism=1、--skip-lock-tables（权衡一致性）及正确建库与外键处理。
mysqlpump 备份时为什么卡住不动，或报错 Access denied
mysqlpump 默认启用并行导出和元数据锁（MDL）一致性快照，但线上库若存在长事务、未提交事务或低权限账号，就会卡在 LOCK TABLES 或 FLUSH TABLES WITH READ LOCK 阶段，甚至直接拒绝连接。
- 必须用具备
SELECT、LOCK TABLES、SHOW VIEW、TRIGGER权限的账号运行，仅SELECT不够 - 避免在业务高峰执行；若无法停写，加
--skip-lock-tables（但会丢失跨表一致性，适合单表逻辑备份场景） - 确认 MySQL 版本 ≥ 5.7.8 —— 低于此版本不支持
mysqlpump，强行使用会提示command not found或静默失败
如何让 mysqlpump 真正“热”起来：避开锁与主从延迟放大
所谓“热”，不是完全无锁，而是尽量减少阻塞时间、不中断写入。关键在控制锁粒度和并发行为。
- 用
--single-transaction替代全局锁（仅对 InnoDB 表有效），它靠 MVCC 快照保证一致性，不阻塞 INSERT/UPDATE/DELETE - 禁用并行导出：
--default-parallelism=1，否则多线程争抢 MDL 容易触发锁等待，反而更慢 - 跳过日志表、临时统计表等非核心数据：
--exclude-databases=sys,information_schema,performance_schema - 若主库启用了
binlog_format=STATEMENT，且备份期间有大量非确定性函数（如NOW()、UUID()），可能加剧从库延迟——建议提前切为ROW格式
备份文件恢复时常见失败：Unknown database 或 Cannot add or update a child row
mysqlpump 默认不导出 CREATE DATABASE 语句，也不保证外键约束顺序，直接 mysql 很容易失败。
- 强制生成建库语句：
--include-databases=mydb（不能只写--databases mydb，后者是 mysqldump 的写法） - 关闭外键检查再导入：
mysql -e "SET FOREIGN_KEY_CHECKS=0;" mydb - 注意字符集：若原库是
utf8mb4_0900_as_cs，而目标 MySQL 版本 Unknown collation —— 此时需用--set-gtid-purged=OFF --default-character-set=utf8mb4并手动替换 collation
对比 mysqldump：什么情况下别硬换 mysqlpump
mysqlpump 不是万能替代品。它的优势在并行和可过滤性，但代价是兼容性窄、行为更“激进”。
- MySQL 5.6 及更老版本不支持，别试；MariaDB 全系不支持
mysqlpump - 含大量 MyISAM 表？放弃
--single-transaction，只能退回到--lock-all-tables，那就真不“热”了 - 需要压缩传输？
mysqlpump不内置 gzip，得套 shell：mysqlpump --all-databases | gzip > full.sql.gz，但管道中断会导致备份不完整，线上慎用 - 备份后校验难：mysqldump 有
--tab输出 CSV 方便 diff，mysqlpump 没对应能力
真正稳定的热备，往往不是靠单个工具，而是组合：mysqlpump 做逻辑快照 + xtrabackup 做物理基线 + binlog 增量追平。工具只是链路一环，别让它扛所有责任。
