MySQL不支持直接单库单表恢复，所有方法均为从备份提取后重新导入：mysqldump需手动分离结构与数据并禁用外键检查；--one-database仅适用于含数据库标记的全备且目标库须预先存在；XtraBackup表空间导入要求innodb_file_per_table=ON、结构完全一致且MySQL版本匹配；无备份时恢复成功率极低。
MySQL 不支持直接“只恢复某库/某表”的原子操作，所有所谓“单库单表恢复”本质都是从备份中提取 + 重新导入。能否成功，取决于你用的是什么备份方式、备份文件里有没有目标对象、以及是否满足引擎和权限约束。
用 mysql 命令配合 --one-database 恢复单个库
这个参数只对 mysqldump --all-databases 生成的全备文件有效，且有明显限制：
- 备份文件中必须包含
-- Current Database: `db_name`这类标记（mysqldump默认会加） - 目标库在恢复前**必须已存在**，否则语句会被跳过（不会自动建库）
- 如果备份里有跨库引用（比如视图、存储过程里用了
other_db.table），--one-database会把这部分也过滤掉，导致导入失败 - 命令写法：
mysql -u root -p --one-database target_db < full_backup.sql
从全备 SQL 文件里提取单张表的结构和数据
这是最通用、兼容性最好的方法，但需手动分离 CREATE TABLE 和 INSERT INTO 两部分：
- 提取表结构（含
DROP TABLE和字符集定义）：sed -e '/./{H;$!d;}' -e 'x;/CREATE TABLE `table_name`/!d;q' full_backup.sql - 提取数据（注意大小写和反引号）：
grep -i 'INSERT INTO `table_name`' full_backup.sql - 导入前务必执行
SET FOREIGN_KEY_CHECKS=0;，否则外键约束可能中断导入 - 若原表已存在，建议先重命名或清空，避免主键冲突；不要直接用
INSERT IGNORE或REPLACE替代，它们不处理索引、触发器等元数据
用临时库中转导出指定表（适合大表或结构复杂场景）
当全备文件太大、sed/grep 提取不稳定，或者表依赖其他对象（如函数、事件）时，走中转更可靠：
- 新建临时库：
mysql -e "CREATE DATABASE tmp_recover CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;" - 把全备导入临时库：
mysql tmp_recover < full_backup.sql - 从临时库导出目标表（加
-t跳过建表语句，只导数据）：mysqldump -t tmp_recover table_name > table_data.sql - 再结合之前提取的建表语句，组合成完整可导入文件
- 注意：临时库的 MySQL 版本、字符集、SQL mode 应尽量与生产库一致，否则
mysqldump可能生成不兼容语法
物理备份（XtraBackup）下恢复单表要格外小心
这不是“恢复单表”，而是“把备份里的某个表空间拷进当前实例”，仅适用于 InnoDB 表且 innodb_file_per_table=ON：
- 必须确保目标表结构完全一致（字段顺序、类型、索引、外键名、字符集），差一点就会
IMPORT TABLESPACE失败 - MySQL 8.0.23+ 强制校验
server_uuid和页校验值，从不同实例拷来的.ibd文件大概率报错Tablespace mismatch - 导入前要先
DISCARD TABLESPACE，这会清空当前表数据且不可逆 - 实际生产中，更推荐用 XtraBackup 恢复到临时实例，再用
mysqldump导出表——虽然多一步，但可控性强得多
真正容易被忽略的点是：所有这些方法都假设你有可用备份，且备份时间点早于误操作。如果没有开启 binlog，也没有定期备份，那“恢复单表”就只剩从从库拉、找快照、或尝试 undrop 工具——都不是标准路径，成功率低、风险高。
