--single-transaction仅对InnoDB生效，MyISAM仍锁表；InnoDB需显式指定否则默认全表锁；混合引擎下应分库/分表备份，冷备InnoDB必须打包全部关键文件，MyISAM可单独复制文件。
mysqldump备份时--single-transaction只对InnoDB生效
MyISAM表完全不支持--single-transaction，加了也没用，仍会执行LOCK TABLES阻塞写入。InnoDB表必须显式加这个参数，否则默认也会锁表——不是“自动优化”，而是默认退化为全表锁。
- 混合引擎库中，该参数仅作用于InnoDB表；MyISAM部分照常锁表，可能导致备份期间部分表不可写、部分表可读但数据不一致
- 若库中存在MyISAM表且无法改造，用
--lock-all-tables比默认--lock-tables更稳妥：前者统一锁全部表，避免InnoDB被快照保护而MyISAM裸奔导致逻辑不一致 - 大InnoDB表加
--single-transaction虽免锁，但会延长事务生命周期，可能拖慢长查询或触发undo log膨胀，需监控innodb_max_undo_log_size
冷备文件拷贝：MyISAM能直接复制，InnoDB必须整套打包
MyISAM表停库或加FLUSH TABLES WITH READ LOCK后，复制.frm、.MYD、.MYI三个文件即可恢复。InnoDB不能只拷.ibd——哪怕启用了innodb_file_per_table=ON，单独复制.ibd再ALTER TABLE ... IMPORT TABLESPACE大概率失败。
- 常见报错：
Tablespace is not encrypted but encryption flag is set或Invalid tablespace，本质是.ibd依赖ibdata1中的元数据和ib_logfile*的redo状态，缺一不可 - InnoDB冷备必须打包：
ibdata1（或所有共享表空间文件）、全部.ibd、ib_logfile0/ib_logfile1、mysql/系统库目录、auto.cnf（含server-uuid） - MyISAM冷备只需确保无写入，文件级操作快且容错高；InnoDB冷备一旦漏掉任一文件，启动就报错或数据乱码，恢复成本远高于逻辑备份
崩溃恢复机制差异决定备份策略底线
InnoDB崩溃后靠redo log重放 + undo log回滚自动修复，无需人工干预；MyISAM没日志，断电或异常终止后.MYD极易损坏，必须手动跑REPAIR TABLE，且结果不可控——这意味着MyISAM备份不能只依赖“文件没坏”，还得预估修表失败概率。
- 生产环境严禁用
cp或rsync直接拷InnoDB文件代替mysqldump或Percona XtraBackup等工具：前者跳过内存状态校验，后者能保证一致性点 - MyISAM表若混在InnoDB主库中，备份脚本里别图省事统一用
--single-transaction——它对MyISAM无效，反而掩盖了锁表事实 - 真正关键的不是“能不能备份”，而是“恢复后敢不敢上线”：InnoDB靠日志兜底，MyISAM靠人盯盘，运维成本差一个数量级
备份命令组合建议
混合引擎库最稳妥的实操组合：mysqldump --single-transaction --routines --triggers --databases db1 db2 > backup.sql（覆盖InnoDB），再单独对MyISAM表用mysqldump --lock-all-tables --databases db1 --tables t1 t2 > myisam_only.sql。
- 不推荐
mysqlpump（MySQL 5.7+）分引擎导出：它虽支持--skip-innodb/--skip-myisam，但实际使用中常因版本兼容或权限问题中断，不如手拆明确 - MyISAM表量少时，
SELECT * INTO OUTFILE+LOAD DATA INFILE可绕过锁表，但要求secure_file_priv路径可控且字段格式严格匹配 - InnoDB备份后务必验证：
mysql -e "CHECK TABLE t1;"只是表结构检查，真正要跑mysqlcheck --repair或导入后查关键业务数据行数/校验和
备份不是拷完就完事。InnoDB的ibdata1和ib_logfile*、MyISAM的.MYD损坏概率、以及两者恢复后是否真能对得上业务数据——这些细节藏在日志和文件背后，不碰一次真实故障很难意识到。
