mysqldump 备份时要不要加 --single-transaction
对 InnoDB 表做逻辑备份时，
--single-transaction是关键开关。它通过启动一个一致性快照（REPEATABLE READ 隔离级别）来避免锁表，让备份过程不影响线上写入。
但要注意：它只对 InnoDB 有效，MyISAM 表仍会触发
FLUSH TABLES WITH READ LOCK，导致全局只读；如果库中混用引擎，备份可能卡在 MyISAM 表上。 纯 InnoDB 库：必须加，否则默认会锁全库 含 MyISAM 表：要么先转成 InnoDB，要么改用
--lock-tables=false+
--skip-lock-tables（但数据一致性不保证） 备份大表前建议确认
innodb_lock_wait_timeout是否足够长，否则事务可能被中断
恢复时遇到 ERROR 1046 (3D000): No database selected
这是最常见的导入失败提示，本质是 SQL 文件里没有
USE database_name;语句，或
mysql命令没指定目标库。
两种典型场景：
用mysqldump -u root -p mydb > backup.sql导出的文件，默认包含
CREATE DATABASE和
USE mydb，但恢复时若手动执行
mysql -u root -p ，而当前 MySQL 实例禁用了 <code>CREATE DATABASE权限，就会跳过建库步骤，后续
USE失败 导出时用了
--no-create-db或
--databases参数组合不当，导致 SQL 文件头部缺失上下文
稳妥做法是显式指定库名：
mysql -u root -p mydb < backup.sql
或者在 SQL 文件开头手动插入
USE mydb;（注意不能放在
CREATE DATABASE之前）。
物理备份（xtrabackup）恢复后无法启动 mysqld
Percona XtraBackup 恢复后最常见的启动失败原因是未正确执行
--prepare步骤，或恢复路径权限不对。
xtrabackup --copy-back只是把文件拷过去，必须先用
xtrabackup --prepare回滚未提交事务、前滚已提交事务，否则
ibdata1和日志状态不一致 恢复目录（如
/var/lib/mysql）必须属主为
mysql:mysql，且不能残留旧的
ib_logfile*—— 这些文件会被 mysqld 启动时校验，大小/内容不匹配直接报错退出 如果原备份来自高版本 MySQL（如 8.0.32），恢复到低版本（如 8.0.23）会因 redo log 格式不兼容而失败，XtraBackup 不做向下兼容处理
备份文件校验与增量恢复的衔接点
逻辑备份（
mysqldump）本身不提供内置校验机制，
md5sum只能验证传输完整性，无法判断 SQL 是否可执行成功；物理备份（
xtrabackup）则依赖
--stats和恢复后的
innodbchecksum扫描。
增量恢复真正容易出问题的地方在 binlog 位置衔接：
全量备份后，mysqldump --master-data=2会在输出中记录
CHANGE MASTER TO的
File和
Position，但这个位置是备份开始时刻的位点，不是结束时刻——中间可能有新事务写入 用
xtrabackup做增量时，
--incremental-basedir必须指向 prepare 后的全量目录，而不是原始备份目录；否则
xtrabackup_info中的
to_lsn与
from_lsn对不上，prepare 增量时会报错
实际操作中，别只信备份命令输出的最后一行 position，要用
mysqlbinlog --base64-output=decode-rows -v翻看对应 binlog 文件，确认该 position 后第一条事件是否合理。
