mysqldump是单表备份最稳妥的快速方案，支持结构+数据一步导出，加--single-transaction可避免锁表，配合--routines、--triggers确保完整，生成SQL文件可跨实例还原。
直接用 mysqldump 是最稳妥的“快速”方案——它默认导出结构+数据，不依赖临时表、不锁死写入（加 --single-transaction 时），且生成的 SQL 文件可跨实例还原。
用 mysqldump 备份单表：结构+数据一步到位
命令格式固定，但几个参数决定成败：
mysqldump -u root -p --single-transaction --routines --triggers database_name table_name > backup.sql-
--single-transaction对 InnoDB 表关键：避免锁表，保证备份期间写操作不受阻 - 漏掉
--routines或--triggers，备份文件里就不会有存储过程和触发器定义 - 如果表很大（>1GB），加上
--quick防止客户端内存溢出；加--compress可减少网络传输量（远程备份时有效） - 导出路径必须是 MySQL 客户端可写位置，不是服务器磁盘路径——别误写成
/var/lib/mysql/...
想更快？CTAS（CREATE TABLE ... AS SELECT）适合只读快照场景
这招本质是建一张新表并灌入当前数据，执行快、不生成外部文件，但有硬伤：
- 语句形如：
CREATE TABLE backup_table AS SELECT * FROM original_table; - 只复制字段定义和数据，丢失索引、主键、自增、外键、约束、触发器、字符集设置
- 源表被长时间读取时，RR 隔离级别下可能阻塞其他写事务（尤其没加 WHERE 条件全表扫）
- 不能跨库或跨实例，也不能压缩或加密，纯本地瞬时操作
- 恢复时得手动重建索引等对象，不适合做正式备份，仅限临时调试或测试快照
为什么不用 SELECT INTO OUTFILE？它不满足“结构+数据”需求
这个命令只导出数据行，完全不带建表语句：
- 例如：
SELECT * FROM t_user INTO OUTFILE '/tmp/t_user.csv' FIELDS TERMINATED BY ','; - 输出的是纯文本（CSV/TSV），没有
CREATE TABLE，没有字段类型、约束信息 - 需要 FILE 权限，且文件路径必须是 MySQL 服务端本地路径（不是你本地机器）
- 无法处理 NULL、特殊字符、换行符等边界情况，导入时容易报错
- 只适合导出子集数据（比如按时间筛选），不能替代完整表备份
物理文件复制不推荐用于单表日常备份
直接拷贝 .ibd 文件看似最快，但实际门槛高、风险大：
- 必须先执行
FLUSH TABLES table_name WITH READ LOCK;，短暂锁表；解锁前不能写入 - 需确保目标实例的 MySQL 版本、页大小、字符集、innodb_file_per_table 设置完全一致
- 单独拷贝
.ibd不包含表定义（.frm已弃用，但元数据仍需从数据字典同步），恢复时大概率报错Tablespace is missing for table xxx - 跨主机或跨版本基本不可用，连
ALTER TABLE ... IMPORT TABLESPACE都要先DISCARD TABLESPACE，步骤繁琐易错
真正“快速又可靠”的单表备份，还是回到 mysqldump ——别省略 --single-transaction，别跳过 --routines 和 --triggers，导出后顺手 gzip 压缩。那些看起来更快的方式，往往在恢复那一刻才暴露代价。
