MySQL不支持直接恢复单表而不覆盖其他数据，必须依赖已有备份或binlog，通过提取结构与数据、禁用外键/唯一检查、使用临时库中转或mysqlpump导出等方式安全导入。
不能直接“恢复指定表而不覆盖其他数据”——MySQL 没有原子级的单表还原命令。所有可行方案都依赖你**已有备份或 binlog**，且必须手动隔离目标表的结构与数据，再以非破坏性方式导入。关键不是“怎么恢复”，而是“怎么避免覆盖”。
从 mysqldump 全备中提取并安全导入单表
这是最常见也最容易出错的路径。全备文件里混着所有库所有表，直接 mysql -u root -p db_name 会覆盖整个库。
- 先确认目标表在备份中的位置：
grep -n "CREATE TABLE `user_info`" full_backup.sql，记下起始行号 - 用
sed精确截取结构块（含DROP TABLE和字符集定义）：sed -n '/^-- Table structure for table `user_info`/,/^-- Table structure for table `/p' full_backup.sql > user_info_struct.sql；注意结尾匹配要严格，否则可能多截一张表 - 单独提取数据：
awk '/^INSERT INTO `user_info`/ {print; while (getline line > 0 && line !~ /^INSERT INTO `/) print line}' full_backup.sql > user_info_data.sql——比grep更可靠，能处理跨行 INSERT - 导入前必须执行：
SET FOREIGN_KEY_CHECKS=0;，否则外键约束会让INSERT中断；导入完成再开：SET FOREIGN_KEY_CHECKS=1; - 不要直接
INSERT IGNORE或REPLACE INTO：它们跳过主键冲突但不重建索引、不触发触发器、不更新统计信息，后续查询可能异常
用临时库中转导出，彻底规避生产库风险
当全备文件巨大、表有视图/函数依赖，或你不敢直接操作生产库时，临时库是最稳妥的中转方式。
- 建空临时库：
mysql -e "CREATE DATABASE tmp_recover CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;" - 把全备导入临时库：
mysql tmp_recover （确保该库无同名表残留） - 从临时库导出目标表数据（跳过建表语句）：
mysqldump -t tmp_recover user_info > user_info_data_only.sql - 把之前提取的
user_info_struct.sql和user_info_data_only.sql合并成完整可执行文件，再导入生产库 - 务必检查临时库与生产库的
sql_mode是否一致，否则mysqldump可能生成不兼容语法（如STRICT_TRANS_TABLES缺失导致字段截断）
用 mysqlpump 替代 mysqldump 做原生单表导出
如果你控制备份流程，mysqlpump 是比手工切 SQL 更干净的选择，但它默认行为仍可能误覆库。
- 导出命令：
mysqlpump --user=root --password --databases mydb --tables user_info > user_info.sql - 生成的文件开头有
CREATE DATABASE IF NOT EXISTS `mydb`和USE `mydb`，直接导入会重建库 —— 必须手动删掉这两段，只留CREATE TABLE和INSERT -
mysqlpump默认启用--skip-definer，但若原表含存储过程或事件，需额外加--skip-routines --skip-events，否则导入时报权限错误 - 账号需有
PROCESS权限，否则报Access denied; you need (at least one of) the PROCESS privilege(s)
binlog 回滚恢复时如何精准定位且不波及其他表
仅适用于误删/误更新场景，且要求 binlog_format = ROW。它不恢复 DDL（如 DROP TABLE），也不能补全缺失的建表语句。
- 先定位日志范围：
mysqlbinlog --base64-output=DECODE-ROWS -v mysql-bin.000012 | grep -A 5 -B 5 "`user_info`"，观察上下文确认是否为你要的操作 - 用
--start-datetime和--stop-datetime截出区间，导出为 SQL：mysqlbinlog --start-datetime="2026-08-12 14:00:00" --stop-datetime="2026-08-12 14:05:00" mysql-bin.000012 > user_info_changes.sql - 人工删除文件中所有非
user_info表的语句（包括USE other_db切库指令），否则会切换到错误库执行 - 若误操作是
DELETE，可用binlog2sql工具自动生成反向INSERT；但注意它不处理ON DELETE CASCADE引发的连带删除，这部分得人工补 - 导入前关闭唯一键检查：
SET unique_checks=0;，导入后再开，加速大批量插入
真正容易被忽略的点是字符集和 SQL mode：哪怕结构和数据都对，如果备份文件头是 SET NAMES latin1 而你的库是 utf8mb4，中文会变乱码；如果备份时 sql_mode 包含 NO_ZERO_DATE 而恢复时没设，0000-00-00 日期会被拒绝插入。这些细节不验证，恢复后数据看似正常，实则已损坏。
