mysqldump --single-transaction仅对InnoDB表有效，要求REPEATABLE READ隔离级别，备份时通过MVCC创建一致性快照；遇MyISAM表、DDL操作或长事务会失效，需提前验证引擎并管控环境。
mysqldump --single-transaction 什么时候有效
它只对 InnoDB 表起作用，且要求事务隔离级别是 REPEATABLE READ（MySQL 默认值）。备份开始时会启动一个快照事务，后续所有表读取都基于这个一致性视图——哪怕备份过程中有新写入，也不会影响导出内容。
- 对 MyISAM 表完全无效：
--single-transaction不会锁 MyISAM 表，备份可能跨多个时间点，导致不一致 - 备份期间不能执行 DDL：如
ALTER TABLE、DROP INDEX，否则mysqldump会报错退出 - 长事务会阻塞快照建立：若已有未提交事务运行超 60 秒，
mysqldump可能卡在Waiting for table flush状态，需先查SHOW PROCESSLIST - 必须搭配
--master-data=2才能记录 binlog 位点，否则无法做时间点恢复
Percona XtraBackup --no-lock 的真实含义
--no-lock 不是“零锁”，而是跳过 SQL 层的全局读锁，改用底层文件系统级协调。它直接拷贝 ibdata1 和 .ibd 文件，同时持续监听并捕获 redo log 变化，最后通过 xtrabackup --apply-log 回放日志达成一致性。
- 仅支持 InnoDB/XtraDB：MyISAM、Memory、Archive 表不会被备份，也不报错，容易漏掉
- 仍需短暂
FLUSH：毫秒级暂停写入，用于获取 LSN 和 binlog 位置，业务几乎无感 - 依赖
innodb_file_per_table=ON：若关闭，所有表数据都在ibdata1中，--no-lock依然有效，但恢复更复杂 - 务必确认
xtrabackup_logfile存在且大小 > 0：这是应用日志的关键，缺失或为空会导致恢复失败
为什么不能直接 md5sum mysqldump 输出的 SQL 文件
SQL 文本备份本身不具备可比性：注释、时间戳、建表语句顺序、字段排列方式、甚至空格和换行都可能因版本、参数或执行环境不同而变化。哈希值不同 ≠ 数据不一致。
- 唯一能用哈希校验的场景是
mysqldump --tab导出的纯数据文件（如table_name.txt），前提是源库和目标库字符集、字段分隔符、NULL 处理完全一致 -
--tab要求 MySQL 用户有FILE权限，且 InnoDB 表导出时可能丢失事务边界，不推荐用于核心业务表 - 真正有效的校验必须在恢复后进行：比如用
mysqlcheck -u root -p --check --extended db_name快速发现表损坏、行数异常、索引失效等高频问题
pt-table-checksum 校验的是什么
它不验证备份文件，也不比对 SQL 内容，而是运行在源库（或已恢复的测试库）上，按 chunk 计算每段数据的校验和，并将结果写入专用 checksum 表。目标库执行 pt-table-sync 时读取该表，定位不一致的 chunk 范围。
- 校验的是逻辑一致性：字段值、NULL/NOT NULL、JSON 格式、TEXT 截断等都能发现，但不保证物理页结构一致
- 必须在源库执行：不能在备份文件上跑，也不能在没恢复的空库上跑
- 大表默认分 chunk（如 1000 行一组），避免单次查询锁表太久；可通过
--chunk-size调整 - 若某张表校验失败，优先查
SELECT COUNT(*)和SELECT MIN(pk), MAX(pk)是否匹配——很多不一致其实只是主键缺失或自增偏移
--single-transaction 漏掉，整个备份就失去逻辑一致性。要么单独用 --lock-tables 备份它，要么提前转换引擎，别指望靠事后校验来兜底。 
