无主键导致回滚不精准，因ROW格式binlog依赖主键或唯一索引定位行；无主键时只能记录全字段镜像，但解析工具无法唯一锚定目标行，易误匹配、漏恢复或重复写入。
不能直接“精准撤销”——ROW 格式 binlog 里确实记录了被改/删的行数据，但没有主键时，my2sql 或 binlog2sql 生成回滚语句会失去唯一定位依据，容易误匹配、漏恢复或重复写入。
为什么没有主键会导致回滚不精准
MySQL 的 ROW 格式 binlog 在记录 UPDATE/DELETE 事件时，依赖表结构中的“唯一标识能力”来区分行。有主键或唯一索引时，binlog 会把 key 列值作为定位锚点；没有主键时，它只能记录整行所有字段的 before_image 和 after_image，但还原时无法保证哪一行对应哪一条变更。
- UPDATE 场景：
UPDATE t SET status=2 WHERE name='alice'（name 不唯一）→ binlog 里可能有 5 行 name='alice'，但你不知道哪一行是误操作目标 - DELETE 场景：
DELETE FROM t WHERE type='tmp'→ binlog 记录了所有被删行的完整字段，但执行回滚 INSERT 时，如果表里已有相同内容的行，会违反唯一约束或造成重复 - 工具行为：像
my2sql默认按WHERE (col1, col2, ...) = (val1, val2, ...)生成条件，一旦存在重复组合，就可能命中多行或零行
必须先补救表结构再解析 binlog
别跳过这步——临时加唯一约束不是为了长期使用，而是让 binlog 解析器能稳定锚定每一行。操作本身不修改数据，只影响后续解析逻辑。
- 用
SHOW CREATE TABLE t查看当前表结构，确认无主键且无任何唯一索引 - 在测试库中执行：
ALTER TABLE t ADD COLUMN _tmp_id BIGINT UNSIGNED AUTO_INCREMENT FIRST, ADD PRIMARY KEY (_tmp_id)（注意：加在 FIRST 是为避免影响已有字段顺序，AUTO_INCREMENT 不会重写历史数据） - 用
mysqlbinlog --base64-output=decode-rows -vv检查该表后续 binlog 事件，确认 now 有_tmp_id出现在 before_image 中 - 注意：此操作仅用于构造解析上下文，恢复完立刻
DROP COLUMN _tmp_id，不要在生产表上长期保留
用 my2sql 时必须显式指定 row-image 和条件字段
my2sql 默认假设表有主键。面对无主键表，必须靠参数强制指定“哪些字段组合能代表一行”，否则输出的 SQL 极可能错位。
- 先确认 binlog 中实际记录的字段全集：
mysqlbinlog --base64-output=decode-rows -vv binlog.000027 | grep -A10 "### UPDATE" | head -20 - 选一组高区分度字段（例如
user_id, created_at, ip），确保在误操作时间窗口内无重复 - 运行解析命令时加
--flashback --where "user_id=%s AND created_at='%s' AND ip='%s'"，并配合--row-image FULL（默认就是 FULL，但显式写更稳妥） - 严禁使用
--no-primary-key这类模糊开关——它只是跳过检查，不解决定位问题
最后一步永远是人工核对 before_image 内容
即使工具输出了 SQL，也必须打开原始 binlog 文件，逐条比对 ### UPDATE 块里的 ### WHERE 和 ### SET 部分，确认字段值与业务逻辑吻合。特别是：
- 时间字段是否带毫秒？
created_at在 binlog 里可能是'2026-09-02 14:22:33.123'，而你的 WHERE 条件若只截到秒级，就会漏掉 - 字符串是否含不可见字符？比如
name字段前后有空格或 \t，在 binlog 里会原样显示，但 SELECT 查询时可能被 trim 掉 - NULL 值是否被正确识别？binlog 里用
### @1=NULL表示，但某些工具会转成IS NULL或空字符串，需手动修正
没有主键的大表 binlog 恢复，本质是“用字段组合模拟主键”。工具只是辅助，最终决定哪一行该被还原、哪一行该被跳过的，只能是你自己盯着 ### 开头的原始事件行做判断。
