MySQL全库备份无法真正秒级，但可通过优化接近秒级停机窗口：MyISAM表需FLUSH TABLES WITH READ LOCK，应优先转为InnoDB；必须保留时单独低峰期导出；XtraBackup是唯一支持混合引擎热备的工具。
MySQL 全库备份不可能真正“秒级”，但可接近秒级停机窗口
所谓“秒级全库备份”，实际是指备份过程中对业务影响极小（如主库锁表时间 mysqldump --single-transaction 或 Percona XtraBackup）能实现近乎无锁，MyISAM 则必须全局读锁，无法规避秒级阻塞。真实场景中，混合引擎库若含 MyISAM 表，FLUSH TABLES WITH READ LOCK 会卡住所有 DML，哪怕只持续 0.5 秒，也可能触发应用超时。
用 mysqldump --single-transaction 备份 InnoDB 表的实操要点
这是最常用、零额外组件的方案，依赖 InnoDB MVCC 实现一致性快照，不锁表，但有严格前提：
- 数据库必须全部使用 InnoDB 引擎；一旦遇到 MyISAM 表，
--single-transaction自动失效，退化为逐表加锁 - dump 过程中不能执行
ALTER TABLE、DROP TABLE等隐式提交 DDL，否则事务快照中断，导致部分表非一致 - 务必加上
--skip-lock-tables（显式禁用锁），否则 mysqldump 可能在某些旧版本中误加LOCK TABLES - 推荐命令：
mysqldump --single-transaction --skip-lock-tables --routines --triggers --databases db1 db2 > backup.sql
MyISAM 表无法避免读锁，但可最小化影响
MyISAM 不支持事务，mysqldump 对其只能走 FLUSH TABLES WITH READ LOCK + SELECT 路径。关键不是“怎么跳过锁”，而是“怎么让锁时间最短”：
- 先用
SHOW TABLE STATUS WHERE Engine = 'MyISAM'找出所有 MyISAM 表，评估是否真需保留——多数场景可ALTER TABLE t ENGINE=InnoDB迁移 - 若必须保留，把 MyISAM 表单独导出：
mysqldump --lock-tables --databases myisam_db > myisam.sql，并安排在低峰期执行 - 不要混用
--single-transaction和 MyISAM 表，否则 mysqldump 会静默忽略该参数，且不报错 - 注意
read_buffer_size和磁盘 I/O：MyISAM 全表扫描导出速度直接受此影响，增大read_buffer_size（如 2M）可减少系统调用次数
XtraBackup 是唯一能真正“热备混合引擎”的工具，但代价明确
Percona XtraBackup 对 InnoDB 做物理拷贝 + redo 日志追加，对 MyISAM 则在 FLUSH TABLES WITH READ LOCK 后直接 cp 文件——它把锁时间压缩到文件系统级拷贝启动前，通常
- 备份命令示例：
xtrabackup --backup --target-dir=/backup/full_$(date +%F) --parallel=4
- 它不生成 SQL，恢复需
--prepare步骤，且要求 MySQL 版本严格兼容（如 8.0.33 备份不能用于 8.0.34 实例） - MyISAM 文件被复制时若正被写入（如日志表），可能损坏；务必确认这些表是只读或有应用层写保护
- 备份目录占用空间 ≈ 数据文件大小，且
--stream=xbstream流式备份虽省本地磁盘，但网络抖动会导致备份中断且不可续传
真正难的不是选工具，而是厘清哪些表可以改引擎、哪些查询会意外中断一致性快照、以及锁住那不到一秒的时间点，是否恰好卡在支付回调的 UPDATE 上。
