对InnoDB表逻辑备份必须加–single-transaction，它通过REPEATABLE READ快照避免锁表；但仅对InnoDB有效，混用MyISAM会导致全局只读或卡住。

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 实例禁用了 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 后第一条事件是否合理。

https://www.php.cn/faq/1963943.html