单表恢复需结合备份与binlog：逻辑备份用mysqldump提取并导入；物理备份需innodb_file_per_table=ON且含--export；binlog恢复依赖ROW格式及精准定位；预防重于恢复，须合理配置参数并定期演练。
单张 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 - 测试恢复流程——至少每季度对一个非关键表执行完整恢复演练
