MyISAM 备份用表级锁（--lock-tables），备份期间库只读；InnoDB 默认用一致性快照（--single-transaction），支持备份时写入，但需无长事务阻塞。
mysqldump 备份时，InnoDB 和 MyISAM 行为差异在哪
关键区别不在命令本身，而在锁机制和一致性保证方式。默认情况下 mysqldump 对 MyISAM 表用 --lock-tables（锁全库表），对 InnoDB 表则倾向用 --single-transaction（开启一致性快照）。这意味着：MyISAM 备份期间整个数据库基本只读；InnoDB 可以边备份边写入，但前提是事务隔离级别支持且无长事务阻塞。
- MyISAM 不支持事务，
--single-transaction对它无效，强行加会报 warning，实际仍走表级锁 - InnoDB 若存在运行超 1 分钟的事务，
--single-transaction可能卡住或导致备份不一致 - 混合引擎库（比如系统表用 MyISAM，业务表用 InnoDB）必须用
--lock-all-tables才能保证全局一致性，否则备份中途可能有跨引擎数据错位
物理备份恢复时，InnoDB 的 ibdata1 和 redo log 必须成套处理
MyISAM 恢复只要把 .MYD/.MYI 文件复制回去、修好权限、重启 mysqld 就行；InnoDB 完全不是这样——ibdata1 是共享表空间，ib_logfile* 是重做日志，二者版本、大小、checksum 必须严格匹配。直接替换文件大概率启动失败，报错如 InnoDB: The log sequence number in ibdata files does not match... 或 Cannot continue operation。
- 用
xtrabackup做物理备份后，恢复前必须先执行innobackupex --apply-log，否则ibdata1里有未刷盘的脏页，直接--copy-back会损坏数据 - 手动 cp 数据文件恢复仅适用于：MySQL 已停机 + 所有表为独立表空间（
innodb_file_per_table=ON）+ 确认没未提交事务 + redo log 与数据文件同源 - MyISAM 没有类似机制，所以恢复快、容错高，但也意味着崩溃后无法回滚未完成的操作
增量备份只能用 xtrabackup，且只对 InnoDB 有效
mysqldump 是逻辑备份，没有“增量”概念；真正意义上的增量备份依赖 InnoDB 的 redo log 记录物理页变更，MyISAM 没有这种日志结构，xtrabackup 对 MyISAM 表只能做全量拷贝。
-
xtrabackup --incremental的 base 目录必须是上一次--backup或--incremental的输出，不能混用不同时间点的全备目录 - MyISAM 表在增量备份中会被跳过或触发警告，最终备份集里不包含它——这点极易被忽略，导致恢复后部分表丢失
- 若库中既有 InnoDB 又有 MyISAM 表，建议统一迁移到
innodb_file_per_table=ON+ 全部使用 InnoDB，否则备份策略得拆成两套，运维成本陡增
恢复验证时，别只看 “SQL 执行成功”，要查数据一致性
逻辑恢复（mysql -u ... ）容易给人“恢复完成了”的错觉，但 MyISAM 表可能因中断写入产生索引损坏，InnoDB 表可能因字符集不匹配导致乱码或截断，而这些都不会报错。
- 恢复后立即执行
mysqlcheck -u root -p --check --repair database_name，尤其对 MyISAM 表 - InnoDB 恢复后检查
SHOW ENGINE INNODB STATUS\G中是否有LOG PARSED UPTO异常或pending状态 - 哪怕用了
--single-transaction，也要核对备份前后SELECT COUNT(*)和关键业务字段的CHECKSUM TABLE值是否一致
最常被跳过的环节是跨引擎校验——比如备份时用了 --single-transaction，却忘了 MyISAM 表根本没进快照，恢复后那几张表还是旧的。
