对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 实例禁用了 <code>CREATE DATABASE权限，就会跳过建库步骤，后续USE失败 - 导出时用了
--no-create-db或--databases参数组合不当，导致 SQL 文件头部缺失上下文
稳妥做法是显式指定库名：
MMM金融互助系统源码是以thinkphp为核心进行开发的3m金融互助平台。程序安装说明：1.恢复数据：将“数据备份”文件夹中的 urkeji.sql 文件请采用phpMyAdmin进行导入； 2.配置Sql数据库信息，文件路径：根目录下 config.php3.后台管理地址：http://域名/admin.php 用户名：100000 密码：admin1
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 后第一条事件是否合理。
