mysqldump 不能直接按存储引擎过滤表，需先通过 information_schema.tables 查询目标引擎的表名再传入；myisam 可文件拷贝但须加读锁并备份 .frm；innodb 物理备份必须用 xtrabackup 等工具保证一致性。
mysqldump 能否按存储引擎过滤表
不能直接按引擎过滤，mysqldump 没有 --engine=InnoDB 这类参数。它操作的是逻辑层的数据库/表结构，不感知底层引擎类型。但你可以先查出目标引擎的表名，再传给 mysqldump。
常见做法是用 INFORMATION_SCHEMA.TABLES 筛选：
SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = 'your_db' AND ENGINE = 'InnoDB';
然后拼成命令，例如：
mysqldump your_db t1 t2 t3 > backup_innodb.sql
- 注意：不同引擎混合在同一个库中时，必须手动分离表名，否则备份会包含所有表
-
MyISAM表支持快速拷贝文件（见下一条），而InnoDB表若启用innodb_file_per_table，单表 .ibd 文件可单独复制，但需配合FLUSH TABLES WITH READ LOCK和mysqldump --no-create-info才安全 - 跳过
MEMORY或CSV表——它们不持久化或格式特殊，直接 dump 可能报错或丢失元数据
MyISAM 表能否只复制 .MYD/.MYI 文件
可以，但仅限于 MySQL 完全停止或表已显式加读锁（FLUSH TABLES tbl_name WITH READ LOCK）时。因为 MyISAM 是文件级锁，没有事务和崩溃恢复机制，裸拷文件极易损坏。
实操要点：
- 运行
FLUSH TABLES your_table WITH READ LOCK;后，立刻复制your_table.MYD和your_table.MYI - 不要复制
.frm文件？错——.frm存字段定义，必须一并备份，否则还原时无法识别结构 - 跨版本恢复风险高：
MyISAM格式在 5.7 和 8.0 间有细微差异，建议用mysqlcheck --repair验证 - 不推荐用于生产环境定期备份：缺乏一致性校验，且无法做增量
InnoDB 表做物理备份为什么必须用 xtrabackup 或 mysqlbackup
因为 InnoDB 的数据文件（ibdata1、.ibd）受缓冲池、redo log、undo log 多重状态影响，直接拷贝会导致“页校验失败”或启动时报 Tablespace is missing。
Percona XtraBackup 是事实标准，关键行为：
- 自动追踪
lsn（日志序列号），备份过程中持续捕获 redo log 变更，保证最终一致性 - 支持流式备份 + 增量：
xtrabackup --incremental-basedir=base_dir --target-dir=inc_dir - 还原前必须执行
xtrabackup --prepare，把增量日志合并进备份文件，否则 MySQL 拒绝启动 -
mysqldump对InnoDB是逻辑备份，适合小库或跨版本迁移；xtrabackup 是物理备份，速度快、体积小，但只能同版本还原
备份脚本里如何自动识别并分类引擎类型
写 shell 脚本时，别硬编码表名。用 SQL 查询结果驱动备份流程：
mysql -Nse "SELECT TABLE_NAME, ENGINE FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA='mydb'" | \
while read table engine; do
case "$engine" in
"InnoDB") echo "dump $table via mysqldump --single-transaction";;
"MyISAM") echo "copy $table files with lock";;
*) continue;;
esac
done
注意事项：
-
-N去除列名，-s禁用表格对齐，避免空格干扰解析 - 实际脚本中要加入错误处理：
|| { echo "query failed"; exit 1; } - 别忽略
TEMPORARY表和视图——它们没有引擎属性，ENGINE字段为NULL，直接参与循环会出错 - 如果库中有分区表，
INFORMATION_SCHEMA.PARTITIONS才能查到每个分区的引擎，主表信息可能不准
引擎差异带来的备份方式分裂，本质是数据持久化模型不同：MyISAM 依赖文件系统原子性，InnoDB 依赖 WAL 和内存状态一致性。混用备份策略不光低效，还容易在恢复时才发现某张表根本打不开。
