mysqldump 备份时加 --single-transaction 还是 --lock-all-tables？
对运行中的 InnoDB 库做逻辑备份，
--single-transaction是更安全的选择。它通过启动一个一致性快照（依赖 MVCC）避免锁表，业务可读写不受影响；而
--lock-all-tables会全局阻塞写入，适合混合引擎或 MyISAM 表较多的旧环境。
注意：该参数仅对 InnoDB 有效，且要求事务隔离级别为 REPEATABLE READ（默认），同时备份过程中不能有长事务在运行，否则可能拉长快照时间、拖慢备份速度。
推荐命令：mysqldump --single-transaction --routines --triggers --databases db1 db2 > backup.sql若库中含 MyISAM 表，
--single-transaction会自动退化为表级锁，此时需评估是否接受短时写入中断 不要在备份命令里漏掉
--routines和
--triggers，否则存储过程和触发器不会被导出
如何用 mysqlbinlog 恢复到指定时间点？
全量备份 + binlog 增量是 MySQL 主流 PITR（Point-in-Time Recovery）方案。关键不是“能不能”，而是“binlog 是否开启”和“position 或时间点是否可定位”。
先确认：
SHOW VARIABLES LIKE 'log_bin';返回
ON，且
SHOW MASTER STATUS;能查到当前 binlog 文件与 position。 恢复前停止应用写入，避免新日志干扰 先导入全量备份：
mysql再重放 binlog 到故障前一秒：
mysqlbinlog --stop-datetime="2024-05-20 14:23:59" mysql-bin.000003 | mysql若已知误操作的 position（比如 DROP TABLE 的起始位置），用
--start-position=12345 --stop-position=12399更精准
备份文件权限不对导致恢复失败？
常见现象是执行
mysql 报错：<code>Access denied for user 'root'@'localhost'或直接卡住无响应——其实不是权限问题，而是 shell 层面的文件权限阻止了读取。 检查备份文件是否可被 mysql 进程用户读取：
ls -l backup.sql，确保属主/属组能读（至少
-rw-r--r--） 如果备份由 root 执行但恢复用普通用户，别忘了
chown mysql:mysql backup.sql（假设 mysql 服务以 mysql 用户运行） 避免把 backup.sql 放在
/root/下却用非 root 用户恢复，Linux 默认禁止其他用户访问 root 家目录
自动备份脚本里忘记清理旧备份，磁盘爆了
定时任务跑通不等于数据安全。很多脚本只管 dump，不管删，三个月后发现
/backup/mysql/占满 2TB。 加一句清理逻辑：
find /backup/mysql -name "*.sql" -mtime +7 -delete（保留最近 7 天） 用
du -sh /backup/mysql在脚本末尾加校验，超阈值（如 50G）就发告警或退出 别用
rm -rf /backup/mysql/*.sql，容易手抖写成
rm -rf /backup/mysql/*，删掉整个目录
真正难的不是备份动作本身，而是让备份可验证、可清理、可追溯。每次写完脚本，手动跑一次
mysql --one-database testdb 看是否真能还原，比什么都靠谱。
