单表恢复需据备份类型选择路径：mysqldump需手动截取结构与数据，binlog恢复须row格式并精确过滤；推荐mysqlpump原生导出；ibd恢复仅限innodb_file_per_table=on且文件完好；慎用ctas避免锁表与内存溢出。
确认备份方式再操作，mysqldump 和 binlog 恢复路径完全不同
MySQL 单表恢复没有“一键回滚”功能，实际取决于你有没有对应备份以及备份类型。如果只有全库 mysqldump 文件，恢复单表就得从 SQL 文件里抽取出目标表的 CREATE TABLE 和 INSERT 语句；如果开启了 binlog 且格式为 ROW，才可能用 mysqlbinlog 精确过滤出该表的变更并反向应用。
常见错误是直接用 grep 在 dump 文件里搜 INSERT INTO `t_user`，但忽略了 INSERT 可能被拆成多行、含注释或跨事务——结果漏数据或语法报错。
- 全量 dump 恢复单表：先用
sed -n '/^-- Table structure for table `t_user`/,/^-- Table structure for table `/p' backup.sql截取结构，再用awk '/^INSERT INTO `t_user`/,/^INSERT INTO `/ {print}' backup.sql抽数据（注意结尾边界） - binlog 恢复单表：必须确保
binlog_format = ROW，然后用mysqlbinlog --base64-output=DECODE-ROWS -v mysql-bin.000001 | grep -A 5 -B 5 't_user'初筛，再结合--start-datetime和--stop-datetime定界 - 别跳过字符集验证：导入前检查 dump 文件头是否有
SET NAMES utf8mb4，否则中文可能变乱码
用 mysqlpump 替代 mysqldump 实现原生单表导出
mysqlpump 是 MySQL 5.7+ 自带的并行逻辑备份工具，支持直接按表粒度导出，比手工切 mysqldump 文件可靠得多。
它生成的 SQL 默认包含 CREATE DATABASE IF NOT EXISTS 和 USE 语句，直接导入会重建库——若只想恢复单表到现有库，得加 --skip-definer --skip-dump-rows=FALSE 并手动删掉开头的库定义部分。
- 导出单表命令：
mysqlpump --user=root --password --databases mydb --tables t_user > t_user.sql - 导入前务必删除文件开头的
CREATE DATABASE和USE行，否则可能覆盖整个库 - 注意权限：执行
mysqlpump的账号需有SELECT+LOCK TABLES权限，否则会报Access denied; you need (at least one of) the PROCESS privilege(s)
误删后无备份？试试从 ibd 文件恢复（仅限 innodb_file_per_table=ON）
如果表是 InnoDB 引擎、启用了 innodb_file_per_table = ON，且物理文件 t_user.ibd 没被 rm -rf 或覆盖，可尝试强制重建表结构后替换文件。但这不是标准流程，成功率取决于 MySQL 进程是否已刷盘、是否有活跃事务锁住该表。
关键限制：MySQL 8.0 后 DISCARD TABLESPACE 要求表处于 IMPORT TABLESPACE 状态，且 .ibd 文件的 space_id 必须和当前表一致——而这个 ID 在 CREATE TABLE 时随机生成，几乎不可能匹配。
- 前置条件：确认
SELECT @@innodb_file_per_table;返回 1，且ls /var/lib/mysql/mydb/t_user.*能看到.ibd文件 - 操作链：
CREATE TABLE t_user (...) ENGINE=InnoDB;→ALTER TABLE t_user DISCARD TABLESPACE;→cp /backup/t_user.ibd /var/lib/mysql/mydb/→ALTER TABLE t_user IMPORT TABLESPACE; - 失败最常见原因：
Tablespace is not empty（没清空原.ibd）、Space id mismatch（ID 不一致）、或Table does not exist（表名大小写不匹配，Linux 下敏感）
线上环境慎用 CREATE TABLE AS SELECT 恢复，容易锁表或爆内存
有人会想“既然旧数据还在其他表或临时表里”，就用 CREATE TABLE t_user_new AS SELECT * FROM t_user_bak WHERE ... 再 rename。这在小表上可行，但对千万级表极易触发 Waiting for table metadata lock，因为 CREATE TABLE ... AS SELECT 会对源表加 MDL_SHARED_READ 锁，阻塞所有 DDL 和部分 DML。
更隐蔽的问题是内存溢出：SELECT 结果集全部加载进内存再建表，若字段含 TEXT 或 BLOB，可能瞬间吃光 buffer_pool。
- 替代方案：用
INSERT INTO t_user_new SELECT * FROM t_user_bak WHERE ... LIMIT 10000分批插入，每次COMMIT - 务必在目标库先
SET autocommit=0，否则每条INSERT都是独立事务，日志写入放大 - 检查
max_allowed_packet是否足够——分批时若某条INSERT含超长字段，仍会报Packets larger than max_allowed_packet are not allowed
单表恢复最耗时间的环节往往不是执行命令，而是判断“该用哪条路”以及验证恢复后的数据一致性。尤其是 binlog 回滚，mysqlbinlog 输出的 @1, @2 变量映射容易看错列顺序，建议先拿测试表练一遍完整流程。
