可精准提取单表dml操作：用mysqlbinlog加--base64-output=decode-rows -v解析row日志，结合grep定位t_user表变更，sed去注释后校验where条件；全量dump切表推荐awk按注释分段提取，物理备份需确认独立表空间及版本兼容性。
用 mysqlbinlog 解析 binlog 提取单表 dml 操作
备份里没单独存表，但你有全量备份 + 后续 binlog，且只丢了 t_user 表的几条记录——这时候别 restore 整库。直接定位到那张表的变更即可。
关键不是“能不能”，而是“在哪段日志里”。mysqlbinlog 支持按库、表、时间点过滤，但默认不解析表名（它只认 USE `db_name` 和 TABLE_MAP_EVENT），所以得加参数：
-
--base64-output=DECODE-ROWS -v：让 row 格式日志可读，否则全是@1=... @2=... -
--database=myapp：先限定库，减少噪音（注意：这个参数对 row 格式仅过滤 USE 语句，不能过滤实际写入的表） - 真正靠得住的是
grep -A 5 -B 5 't_user'配合人工确认——因为TABLE_MAP_EVENT里会明文出现表名 - 提取后别直接
mysql导入，先用sed 's/^### //'去掉注释前缀，再检查WHERE条件是否完整（row 日志里 WHERE 是用旧值拼的，容易漏字段）
从 mysqldump 全备文件中快速切出单表 SQL
如果你的全量备份是文本格式的 mysqldump 输出（不是 --tab 分离数据文件那种），那切表其实很快，但很多人卡在正则写错或忽略分隔逻辑。
核心问题：dump 文件里表结构和数据混在一起，且可能跨多行。不能简单 sed -n '/^CREATE TABLE `t_order`/,/^UNLOCK TABLES/p' ——因为中间可能有 INSERT 跨行、注释、甚至另一个同名临时表。
- 用
awk更稳：awk '/^-- Table structure for table `t_product`$/,/^-- Table structure for table `/ {print}' full.sql > t_product.sql（前提是 dump 用了--comments，默认开启） - 如果 dump 里有
/*!40101 SET @saved_cs_client这类兼容性指令，记得保留，否则导入时可能报Unknown system variable - 删掉开头的
CREATE DATABASE和结尾的UNLOCK TABLES，但别动SET @@SESSION.SQL_LOG_BIN=0——这是为了防止恢复时又写 binlog - 导入前先
CREATE DATABASE IF NOT EXISTS myapp，否则USE myapp会失败
遇到 ERROR 1146 (42S02): Table doesn't exist 却确定表在备份里
常见于从物理备份（如 cp -r /var/lib/mysql/myapp/）恢复单表时。MySQL 不允许直接拷表文件，尤其开了 innodb_file_per_table=OFF 或用通用表空间（ibdata1）时，.ibd 文件根本不能单独用。
- 先查
SELECT TABLE_SCHEMA, ENGINE, CREATE_OPTIONS FROM information_schema.TABLES WHERE TABLE_NAME = 't_log';确认是不是 InnoDB + 独立表空间 - 如果是共享表空间，这条路走不通——必须整库恢复，或者用
mysqlpump（比 mysqldump 更细粒度）重新导出单表 - 即使满足独立表空间，也要严格匹配 MySQL 版本、页大小、校验方式（
innodb_checksum_algorithm），否则ALTER TABLE ... IMPORT TABLESPACE会卡在waiting for handler lock - 别跳过
DISCARD TABLESPACE步骤：不先丢掉原表空间，IMPORT一定失败，错误信息却只报Table not found
勒索场景下，怎么验证备份里真有你要的那张表
攻击者加密后，你第一反应是“赶紧恢复”，但很多团队的备份策略本身就有盲区：比如每天只备份主库，从库的 reporting 库从来没进过备份；或者 mysqldump 加了 --ignore-table=myapp.t_temp 却没人记得。
- 对文本备份（dump），执行
grep -oP 'CREATE TABLE `\K[^`]+(?=`)' backup.sql | sort -u，比肉眼扫快得多 - 对物理备份，进
/var/lib/mysql/myapp/目录看有没有t_config.frm+t_config.ibd（5.7 及以前）或只有t_config.ibd（8.0+），但要注意：空表可能只留.isl文件 - 最致命的坑：备份脚本里用了
mysql -e "SHOW TABLES"但没加--skip-column-names，导致表名前面带列头，后续while read t循环直接崩，某几张表永远没被 dump - 验证完存在，立刻用
head -20 backup.sql | grep t_target确认建表语句是否完整——有些备份因超时或权限中断，最后几张表只有CREATE TABLE没有) ENGINE=
真正耗时间的从来不是操作命令，而是搞清备份到底“是什么格式”“包含什么内容”“缺了哪一环”。尤其是混合使用逻辑备份、物理备份、binlog 归档的环境，表存在≠能用，能切≠能导入，能导入≠数据最新。
