--single-transaction只对innodb有效，因其依赖innodb的mvcc机制和repeatable read隔离级别创建一致性快照；myisam无事务、无undo log，不支持快照，该参数对其无效，mysqldump会静默退化为flush tables with read lock。
mysqldump --single-transaction 为什么只对 InnoDB 有效
因为它的底层依赖 InnoDB 的 MVCC 机制和 REPEATABLE READ 隔离级别。备份开始时执行 START TRANSACTION WITH CONSISTENT SNAPSHOT，后续所有 SELECT 都基于同一事务快照读，不受新提交事务影响。
MyISAM 没有事务、没有 undo log、不支持一致性快照——--single-transaction 对它完全无效，此时 mysqldump 会自动退化为 FLUSH TABLES WITH READ LOCK，但这个行为不报错也不提示，容易误以为“没锁表”。
- 确认引擎类型：
SELECT table_name, engine FROM information_schema.tables WHERE table_schema = 'your_db'; - 混合引擎库中哪怕只有一张 MyISAM 表，整个备份就失去逻辑一致性保障
- MySQL 8.0+ 中
mysqlpump默认并行导出，每个线程单独开事务，库间时间点不同，跨库外键更易断裂
备份期间哪些操作会导致一致性失效
--single-transaction 不阻塞 DDL，但 DDL 会隐式提交当前事务，导致快照失效。一旦发生，后续表的读取将基于新时间点，跨表数据可能错位（比如订单表导出旧状态，用户表导出新状态）。
- 禁止在 dump 过程中执行：
ALTER TABLE、DROP INDEX、TRUNCATE TABLE、RENAME TABLE - 长事务会卡住快照建立：已有未提交事务运行超 60 秒，mysqldump 可能卡在
Waiting for table flush状态 - autocommit=1 时，每个语句自动提交，
START TRANSACTION失效，快照无法维持
--master-data=2 是一致性恢复的前提，不是可选项
仅靠 --single-transaction 能保证“逻辑时间点一致”，但无法定位这个时间点在 binlog 中的位置。没有 --master-data=2，你无法做时间点恢复（PITR），也无法验证主从同步是否覆盖了备份窗口。
-
--master-data=2会在 SQL 文件头部插入类似CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=12345;的注释 - 若用
--master-data=1，语句是可执行的，但会污染备份文件（执行时可能改变目标库状态） - 不加该参数 + 没手动记录
SHOW MASTER STATUS，恢复后只能回滚到备份时刻，无法补漏
真正有效的校验不在备份文件，而在恢复后
直接 md5sum 两个 mysqldump 输出的 SQL 文件毫无意义：注释、字段顺序、空格、时间戳、版本差异都会让哈希值不同，但数据可能完全一致。
必须在目标库恢复后执行校验：
-
mysqlcheck -u root -p --check --extended your_db：快速发现表损坏、行数异常、索引失效 -
pt-table-checksum：按 chunk 计算校验和并写入专用表，适合主从比对，但需在源库或已恢复的测试库上运行 - 业务层校验：比如查关键聚合值（
SUM(balance)）、核对主子表关联数量（SELECT COUNT(*) FROM orders WHERE user_id NOT IN (SELECT id FROM users)）
物理备份（如 xtrabackup）虽快，但恢复后必须跑 xtrabackup --prepare，否则数据文件处于“未合并”状态，MySQL 启动会拒绝加载——这点极易被跳过。
