不是必须，但不加--single-transaction在写入频繁时大概率丢数据；它通过REPEATABLE READ事务保证InnoDB表逻辑一致性，MyISAM需配合--lock-all-tables。
mysqldump 全量备份必须加 --single-transaction 吗？
不是必须，但不加就大概率丢数据。尤其在业务写入频繁的库上，mysqldump 默认执行的是非一致性快照：导出过程中其他事务持续修改表，最终 dump 文件可能包含某张表的旧数据、另一张表的新数据，恢复后主从不一致或应用报错。
加 --single-transaction 会让 mysqldump 在开始时发起一个 REPEATABLE READ 事务，后续所有 SELECT 都基于该事务快照，保证导出逻辑一致。前提是所有表用 InnoDB —— 如果库中混有 MyISAM 表，这个参数会被忽略，必须配合 --lock-all-tables（锁全库，停写）。
- 只对 InnoDB 表生效；MyISAM 表仍需显式加锁
- 备份期间长事务会阻塞 dump 开始，可先查
SELECT TRX_ID, TRX_STARTED FROM INFORMATION_SCHEMA.INNODB_TRX;排查 - 不要和
--lock-tables同时用，后者会覆盖前者行为
怎么确认 binlog 已开启且格式是 ROW？
增量备份依赖 binlog，但它默认可能关闭，或设为 STATEMENT 格式 —— 后者在某些函数（如 NOW()、UUID()）、自增主键、触发器场景下无法精确还原，恢复时数据对不上。
登录 MySQL 执行：
SHOW VARIABLES LIKE 'log_bin';返回
ON 才算开启；再查SHOW VARIABLES LIKE 'binlog_format';必须是
ROW。如果不是，需在 my.cnf 中显式配置：log-bin=mysql-bin<br>binlog-format=ROW并重启 MySQL —— 注意：动态设置
SET GLOBAL binlog_format='ROW' 只对新连接生效，且部分版本不支持运行时切换。
- 仅靠
log_bin=ON不够，binlog_format必须为ROW - MySQL 8.0+ 默认是
ROW，但升级或迁移后建议手动验证 - 如果用 GTID，还要确保
gtid_mode=ON和enforce_gtid_consistency=ON
用 mysqlbinlog 恢复时，怎么精准定位起止 position 或时间点？
恢复不是从头跑 binlog，而是从全备之后的下一个 event 开始。难点在于：全备时间点和 binlog position 并不自动对齐，必须在 dump 时用 --master-data=2 把当前 binlog 文件名和 position 写进 SQL 文件头。
执行 mysqldump --single-transaction --master-data=2 -u root testdb > backup.sql 后，打开 backup.sql，找类似这一行：
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000012', MASTER_LOG_POS=154;这就是恢复 binlog 的起点。用
mysqlbinlog 解析时指定：mysqlbinlog --start-position=154 mysql-bin.000012 | mysql -u root testdb
- 不加
--master-data就只能靠时间估算，误差大，容易跳过或重放事务 -
--start-datetime看似方便，但跨日志文件时无法保证连续性，position 更可靠 - 恢复前务必先停写，或用
FLUSH TABLES WITH READ LOCK（注意锁会影响主从延迟）
误删表后用 binlog 回滚，为什么还是找不到数据？
因为 DROP TABLE 和 TRUNCATE TABLE 是 DDL，binlog 中记录的是语句本身，不是逐行变更 —— 即使是 ROW 格式，也无法通过反向解析还原被删的行。你看到的 binlog event 是 # DROP TABLE `t1` /* generated by server */，没有原始数据。
真正能靠 binlog 恢复的，只有 INSERT/UPDATE/DELETE 这类 DML。DDL 导致的数据丢失，只能依赖最近一次全备 + 全备后到 DDL 前的 binlog（即必须在 DROP 之前截断 binlog）。
- 线上应禁用直接
DROP，改用 rename + 定期清理策略 - 想“回滚 DDL”，得提前开启 MySQL 企业版的 Flashback 功能，或用 Percona Toolkit 的
pt-online-schema-change类工具做灰度 - binlog 不是万能日志，它不保存被删数据的副本，只记录操作意图
最常被忽略的一点：全备和 binlog 是两套独立机制，中间任何一环断掉（比如没定期清理 binlog 导致过期、没校验备份文件是否损坏、没测试恢复流程），整个 RPO 就归零。别只盯着命令对不对，要盯住链路稳不稳定。
