不是必须，但对innodb表几乎总是该加；不加会导致写入阻塞或数据不一致，仅只读库可省略；myisam表不支持该参数，需用--lock-all-tables全局锁表。
mysqldump 逻辑备份必须加 --single-transaction 吗？
不是必须，但对 InnoDB 表几乎总是该加。不加会导致备份期间其他事务写入被阻塞，或备份出的数据不一致（尤其有长事务时）。mysqldump 默认不开启事务一致性，它会逐表 dump，中间可能穿插其他 DML。
- 只读库或确认无并发写入时可省略，但生产环境极少满足
- MyISAM 表不支持
--single-transaction，必须用--lock-all-tables，会全局锁表 - 加了该参数后，
mysqldump会先执行START TRANSACTION WITH CONSISTENT SNAPSHOT，后续所有表读取都基于同一快照 - 注意：长事务会拖住 MVCC 清理，导致
ibdata1膨胀或undo log持续增长
删除前用 CREATE TABLE ... LIKE 做轻量快照够用吗？
够用，但仅限结构 + 当前数据的瞬时副本，不能替代逻辑备份。它本质是 DDL + INSERT SELECT 的快捷写法，不记录 binlog 位置、不包含视图/存储过程、也不处理外键约束依赖顺序。
- 适合快速保留一份“此刻可查”的副本，比如临时排查或灰度验证
- 执行
CREATE TABLE backup_orders LIKE orders; INSERT INTO backup_orders SELECT * FROM orders;前，务必确认orders表没有正在运行的大事务，否则INSERT SELECT可能被锁住或 OOM - 该操作在主库上会生成大量 redo log 和 binlog，从库延迟可能突增
- 不适用于大表（>10GB），因为是全量拷贝，且期间原表仍可写，副本数据已过期
FLUSH TABLES WITH READ LOCK 和快照备份冲突吗？
冲突，而且非常危险——它会让所有写线程卡住，包括复制线程和后台刷新线程。这不是快照机制，而是全局只读锁，MySQL 8.0+ 中还可能触发 Waiting for backup lock 等待状态。
- 不要为了“确保一致性”而手动加这个锁再跑
mysqldump；--single-transaction已足够 - 如果误执行了，用
SHOW PROCESSLIST找到状态为Waiting for table flush的连接，KILL对应 ID 即可释放 - Percona XtraBackup 等物理备份工具内部会协调锁，但普通用户不该自己调用
FLUSH TABLES WITH READ LOCK - 唯一合理使用场景：配合 LVM 快照做秒级停机备份，且必须在锁住后立刻打快照并立即
UNLOCK TABLES
备份文件校验和恢复路径必须提前验证
删表前没验证过备份能否还原，等于没备份。常见问题不是备份失败，而是恢复时才发现字符集不对、SQL mode 不兼容、或 DEFINER 用户不存在。
- 用
head -n 20 backup.sql看开头是否有SET NAMES utf8mb4和正确的sql_mode - 在测试库执行
mysql -u root testdb ，观察是否报错；重点看 <code>ERROR 1231（变量未设置）、ERROR 1449（DEFINER 不存在）、ERROR 1067（默认时间戳非法） - 备份命令里显式加上
--set-gtid-purged=OFF（如不需 GTID）或--triggers --routines --events（如依赖这些对象） - 压缩包别只校验 md5，要
zcat backup.sql.gz | head -n 1确认解压流可读
备份本身不难，难的是删表前那三分钟：有没有真正看过恢复日志、有没有在同版本 MySQL 上跑通过 restore、有没有确认 binlog 位点能回退到删除之前。这些细节漏掉一个，就不是“恢复慢”，而是“恢复不了”。
