单张 MySQL 数据表的恢复，核心依赖于备份与二进制日志（binlog）配合，或使用物理备份中的单表文件（需满足特定条件）。没有通用“一键还原单表”命令，必须结合实际备份策略操作。
从逻辑备份（mysqldump）中恢复单表
这是最常用、兼容性最好的方式。前提是你有定期对目标库或全库执行
mysqldump的习惯，并保留了包含该表的备份文件。 用
grep -n "CREATE TABLE \`表名\`" 备份.sql定位该表在备份文件中的起始位置 再用
sed -n '起始行,结束行 p' 备份.sql > table_dump.sql提取该表结构和数据（注意识别
INSERT INTO \`表名\`后的插入块） 为避免主键冲突或外键约束失败，建议先清空原表：
TRUNCATE TABLE 表名;（慎用，确认无其他依赖）或
DROP TABLE 表名;后再导入 执行
mysql -u 用户 -p 数据库名
从物理备份（如 Percona XtraBackup）中恢复单表
仅适用于启用了
innodb_file_per_table=ON的 InnoDB 表，且备份时使用了
--export选项（XtraBackup 2.4+）或对应流程。 停止 MySQL 服务，或确保目标表未被使用 从备份中找到对应表空间文件（
db_name/table_name.ibd）和配置文件（
table_name.exp） 执行
ALTER TABLE 表名 DISCARD TABLESPACE;卸载当前表空间 复制备份中的
.ibd和
.exp文件到数据库目录，权限设为 mysql 用户所有 执行
ALTER TABLE 表名 IMPORT TABLESPACE;导入 成功后验证数据一致性，必要时运行
ANALYZE TABLE 表名;
利用 binlog 恢复误删/误更新的单表数据
适用于已知误操作时间点或 GTID/position 位置，且 binlog 格式为
ROW（推荐），并开启了 binlog。 用
mysqlbinlog --base64-output=DECODE-ROWS -v 日志文件 | grep -A 5 -B 5 "DELETE FROM \`表名\|UPDATE \`表名\|INSERT INTO \`表名"定位操作 提取误操作前的 binlog 内容，跳过误操作语句，生成回滚 SQL 或重放至指定位置 更稳妥做法：将 binlog 解析为可读 SQL，人工筛选出该表的合法变更，导出为临时 SQL 文件，再导入到临时库或原库中 若开启 GTID，可用
SET gtid_next='xxx'; BEGIN; COMMIT;跳过指定事务（需谨慎评估依赖关系）
预防胜于恢复：让单表恢复更可控
日常运维中降低恢复难度的关键在于设计合理的备份机制。
启用innodb_file_per_table，为物理级单表恢复提供基础支持 对重要业务表，单独做
mysqldump -t -c 数据库名 表名 > 表名.sql（-t 不导结构，-c 加上列名，便于后期解析） binlog 设置
expire_logs_days = 7以上，并定期归档；确认
binlog_format = ROW测试恢复流程——至少每季度对一个非关键表执行完整恢复演练
