能恢复，但必须满足三个前提：MySQL开启binlog、binlog_format为ROW、binlog_row_image为FULL；任一不满足则mysqlbinlog解析出的反向SQL将不完整或失效。
确认是否具备恢复前提条件
没有全量备份或没开 binlog，单表部分恢复基本不可行。先验证三件事：
- 执行
SHOW VARIABLES LIKE 'log_bin';，确认返回值是ON - 执行
SHOW VARIABLES LIKE 'binlog_format';，必须是ROW（STATEMENT或MIXED下部分操作无法精准还原） - 检查
binlog_row_image是否为FULL（MINIMAL会丢字段，导致反向 SQL 缺失关键列）
如果任一条件不满足，mysqlbinlog 解析出来的语句将不完整，后续生成的回滚 SQL 很可能漏数据或报错。
从 binlog 中提取目标表的变更事件
直接用 grep 过滤 mysqlbinlog 输出容易漏掉跨事务的关联操作，也抓不到 UPDATE 前后镜像。正确做法是：
- 用
mysqlbinlog --base64-output=DECODE-ROWS -v解析指定时间段日志，输出含行级变更详情的文本 - 定位到目标表的
### INSERT INTO `db`.`table`、### DELETE FROM `db`.`table`或### UPDATE `db`.`table`区块 - 注意每个事件块开头的
# at xxx位置标记，这是后续跳过/截断的关键偏移 - 不要依赖
grep -A20 -B5 'your_table'—— 它会切碎多行事件，导致解析失败
示例命令：mysqlbinlog --start-datetime="2026-07-01 14:00:00" --stop-datetime="2026-07-01 14:30:00" /var/lib/mysql/mysql-bin.000123 > /tmp/binlog_parsed.sql
生成并校验反向 SQL（不是简单倒序执行）
DELETE 变成 INSERT，UPDATE 要交换 SET 和 WHERE 子句——但实际不能靠手工改。常见陷阱：
- 原
INSERT操作没有主键值时，DELETE后无法精确还原（除非有唯一索引且日志含完整镜像） -
UPDATE若修改了主键或唯一键，反向语句可能因冲突失败，需先DELETE再INSERT - 含自增字段的表，回放前要临时关闭
innodb_autoinc_lock_mode或手动设AUTO_INCREMENT值，否则主键重复 - 建议先导出到测试库执行
SELECT对比，再上生产；别直接mysql -e "source /tmp/rollback.sql"
物理层恢复：仅适用于独立表空间且 .ibd 文件完好
这不是“部分恢复”，而是“替换损坏表空间”。前提是：innodb_file_per_table=ON，且你手上有该表对应的 .ibd 文件（来自 XtraBackup 或冷备）。
- 不能直接复制
.ibd到线上目录——MySQL 会拒绝加载，报错Tablespace is missing for table - 必须先在同结构空库中
CREATE TABLE，再ALTER TABLE ... DISCARD TABLESPACE，再复制文件，最后IMPORT TABLESPACE - 导入前必须确保
ibdata1中的元数据与.ibd的space_id一致，否则报错Invalid or missing tablespace - 该方法绕过 binlog，不会触发复制，主从环境需单独处理从库
真正能“部分恢复”的只有逻辑层（binlog + 行格式），物理层只是换文件，本质是整表还原。
