可用awk精准提取单表SQL：以CREATE TABLE和INSERT INTO目标表名定位起始，用分号判断语句结束，跳过注释与空行，通过状态机控制范围，支持带前缀、反引号及跨行INSERT，避免grep误匹配或截断。
如何用 awk 快速提取 mysqldump 全量备份里的单表 SQL
全量备份文件里混着几十上百张表，但你只缺 user_log 这一张——别还原整个库，awk 就能从 SQL 文件里干净切出它。关键不是“能不能”，而是“怎么避开注释、跨行语句和误匹配”。
核心逻辑是：靠 CREATE TABLE 和 INSERT INTO 的表名匹配定位起始，用分号 ; 判断语句结束，同时跳过注释行和空行。
实操建议：
- 确保备份文件是
mysqldump --single-transaction --routines --triggers生成的（不含--skip-extended-insert更稳妥，否则单条INSERT可能跨多行） - 用
awk -v table="user_log" '...' backup.sql > user_log.sql传入表名，避免硬编码 - 先用
head -50 backup.sql | grep -E "CREATE TABLE|INSERT INTO"确认表定义和插入语句的实际格式（比如是否带数据库前缀`mydb`.`user_log`）
为什么不能只靠 grep -A / -B 提取表结构和数据
grep -A 100 "CREATE TABLE \`user_log\`" 看似简单，但实际会漏掉后续的 INSERT 语句——因为它们不包含表名关键词；而 grep -B 50 -A 200 "INSERT INTO \`user_log\`" 又容易把前面其他表的 CREATE 或 INSERT 拉进来，尤其当备份里有视图、存储过程时，上下文完全不可控。
真正要的是“从 CREATE TABLE \`user_log\` 开始，直到下一个 CREATE TABLE 或文件结尾”，且中间所有 INSERT INTO \`user_log\` 都得保留。这必须靠状态机式处理，awk 的 RS（记录分隔符）或行级状态变量才可靠。
常见错误现象：
- 提取出的 SQL 最后一行是半截
INSERT（没遇到分号就结束了）→ 原因是mysqldump用了--skip-extended-insert，每条记录独立成行，但awk脚本按整行匹配分号，没考虑换行续写 - 结果里混进了
DELIMITER $$和存储过程代码 → 因为脚本没跳过CREATE PROCEDURE块
一个生产可用的 awk 脚本（支持跨行 INSERT 和跳过注释）
下面这个脚本能处理带反引号、数据库前缀、多行 INSERT 的典型 mysqldump 输出：
awk -v table="user_log" '
/^[[:space:]]*--/ { next } # 跳过注释行
/^[[:space:]]*$/ { next } # 跳过空行
/CREATE[[:space:]]+TABLE[[:space:]]+`?[^`\.]+`?\.`?'"$table"'`?/ {
in_table = 1; print; next
}
in_table && /^[[:space:]]*INSERT[[:space:]]+INTO[[:space:]]+`?[^`\.]+`?\.`?'"$table"'`?/ {
print; next
}
in_table && /;/ {
print; in_table = 0; next
}
in_table { print }
/CREATE[[:space:]]+TABLE/ && !/`?[^`\.]+`?\.`?'"$table"'`?/ {
in_table = 0
}' backup.sql > user_log.sql
说明：
- 用
in_table当状态开关，比单纯匹配行更稳 - 正则里
`?[^`\.]+`?\.`?'"$table"'`?能匹配user_log、`user_log`、mydb.user_log、`mydb`.`user_log`四种常见写法 - 遇到任意
CREATE TABLE（非目标表）就关掉状态，防止跨表污染 - 性能上，
awk流式处理 2GB 备份文件也只要几十秒，远快于导入再导出
恢复单表前必须检查的三件事
提取出来的 user_log.sql 不能直接 mysql db_name ，否则大概率报错。
必须手动确认：
-
head -n 5 user_log.sql看第一行是不是CREATE TABLE—— 如果是USE `mydb`;或SET @OLD_...，说明提取逻辑没过滤掉头部元信息，得在awk里加/^USE[[:space:]]+`/ { next }类规则 -
tail -n 5 user_log.sql看最后有没有孤立的COMMIT;或UNLOCK TABLES;—— 这些是全量备份的收尾指令，单表恢复时不仅不需要，还会报错 - 目标库中该表是否已存在？如果存在且结构不一致，
DROP TABLE再CREATE是最安全的；若只想追加数据，得把CREATE TABLE行删掉，只留INSERT
最易被忽略的是字符集和存储引擎声明。比如原备份里是 ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci，但目标 MySQL 版本不支持 utf8mb4_0900_ai_ci，就会卡在 CREATE TABLE 这一步。这时候得用 sed 替换掉 collation 部分，而不是硬扛错误。
