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 和内存状态一致性。混用备份策略不光低效，还容易在恢复时才发现某张表根本打不开。
