精准提取单张表需利用mysqldump的结构特征：以CREATE TABLE 表名开头、独立;结尾，用awk按块匹配最可靠；避免sed误截断，恢复前须检查USE语句、外键、字符集等依赖项。
从 mysqldump 全量备份里精准提取单张表的 SQL
全量备份文件里直接 grep 表名会误匹配注释、其他表字段、甚至库名，根本不可靠。真正能安全提取的，是利用 mysqldump 自身生成的结构分隔特征：每个表以 CREATE TABLE `xxx` 开头，以单独一行 ; 结尾（注意不是语句末尾的分号，而是独立成行的结束符）。
用 sed 提取时必须匹配完整边界，否则会截断或混入其他内容
错误写法：sed -n '/^CREATE TABLE `user`/,/;/p' backup.sql —— 这个会停在第一个 ;，而建表语句里可能有多个分号（比如默认值、触发器、注释），导致提前截断。
正确思路是：找到 CREATE TABLE `表名` 行，再往后一直取到下一个 CREATE TABLE 或文件结尾前的最后一个独立 ; 行。实际更稳的方式是用两段式匹配：
- 先定位建表起始：
/^CREATE TABLE `t_user`/ - 再匹配到下个
CREATE TABLE前的所有行，包括INSERT INTO `t_user`和结尾的独立; - 用
sed -n '/^CREATE TABLE `t_user`/,/^CREATE TABLE `/ { /^CREATE TABLE `t_user`/p; /^CREATE TABLE `/! { /^$/!p; }; }' backup.sql | sed '$d'太绕，推荐用更可控的 awk
更可靠的做法：用 awk 按块切分，避免 sed 的行边界陷阱
awk 能按段落处理，天然适合这种“以空行或特定模式分隔”的 dump 文件（前提是 dump 用了 --skip-extended-insert 或至少没把所有 INSERT 压成一行）。实操命令如下：
awk -v table="t_user" '
/^CREATE TABLE `'"$table"'`/,/^INSERT INTO `'"$table"'`/ {
if (/^CREATE TABLE `'"$table"'`/ || /^INSERT INTO `'"$table"'`/) print;
else if (!/^CREATE TABLE / && !/^INSERT INTO /) print
}
/^CREATE TABLE `[^`]+`/ && !/^CREATE TABLE `'"$table"'`/ { exit }
' backup.sql > t_user.sql
但注意：如果备份里 INSERT 是 extended 格式（一行多条），上面逻辑会漏数据。此时应优先用 mysqlpump 或 mydumper 生成可拆分备份；若只能用 mysqldump，务必加 --skip-extended-insert 参数重做备份。
恢复前必须检查提取出的 SQL 是否完整且无依赖
提取出的 t_user.sql 很可能不包含外键约束定义（如果原库启用了 --skip-triggers --skip-routines --skip-events），也可能缺少前置的 USE db_name;。常见问题：
- 执行时报错
Unknown database→ 手动在开头加USE myapp; - 报错
Cannot add or update a child row→ 表依赖其他表，需先恢复被依赖表，或临时关外键：SET FOREIGN_KEY_CHECKS=0; - 插入失败因自增 ID 冲突 → 加
TRUNCATE TABLE t_user;或用INSERT IGNORE替换原始 INSERT（需 sed 替换）
最易被忽略的是字符集和排序规则：dump 文件头部的 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci 可能与目标库不一致，导致恢复后中文乱码或索引失效。别只盯着表结构，得看 CREATE TABLE 语句末尾那一串。
