myisam 不支持行级变更追踪，因其引擎设计缺失该能力；binlog 仅支持 statement 格式且无法精准定位行变更，触发器也无法可靠捕获行级变更；必须迁移到 innodb 并启用 row 格式 binlog 和事务一致性机制才能实现稳定行级追踪。
MyISAM 本身就不支持行级变更追踪——这不是配置漏了、参数没开，而是引擎设计上压根没这个能力。想靠 binlog 或触发器做细粒度变更记录，必须先换引擎。
为什么 MyISAM 的 binlog 无法精准定位行级变更
MyISAM 表开启 binlog 后，只能记录语句级（STATEMENT）日志，比如一条 UPDATE users SET status=1 WHERE id=100，日志里只存这条 SQL，不存“哪几行被改了”“旧值是什么”。如果 WHERE 条件匹配多行，或语句含函数（如 NOW()），重放时结果可能不一致。
-
ROW格式 binlog 对 MyISAM 无效：MySQL 会自动降级为STATEMENT，SHOW VARIABLES LIKE 'binlog_format'看起来是ROW，但实际写入仍是语句级 - 没有事务支持，
binlog无法与事务原子绑定，ROLLBACK后 binlog 已写入，造成逻辑不一致 - 崩溃后
.MYI/.MYD文件错位，mysqlbinlog解析可能跳过部分事件，丢失变更上下文
触发器在 MyISAM 上无法可靠捕获行变更
MyISAM 允许创建 BEFORE UPDATE 触发器，但受限于表级锁和无事务特性，它无法保证执行顺序和原子性。常见失效场景：
- 并发写入时，多个触发器同时读取同一行旧值，写入审计表时发生覆盖
- 触发器中插入另一张 MyISAM 表，若中途失败，主表变更已生效，审计缺失且无法回滚
- 触发器调用
UUID()或NOW()，不同行记录的时间戳/ID 可能重复（无事务隔离保障）
真正可行的行级变更追踪方案（必须弃用 MyISAM）
只有迁移到 InnoDB，并配合以下机制，才能稳定实现行级变更追踪：
- 启用
binlog_format = ROW，确保每行变更都记录Before_Image和After_Image - 建一张
change_log表，引擎为InnoDB，字段含table_name、row_id、old_data（JSON）、new_data（JSON）、op_type（INSERT/UPDATE/DELETE）、created_at - 用
BEFORE和AFTER触发器组合写入：BEFORE捕获旧值，AFTER写入新值+操作类型，依赖 InnoDB 的事务一致性保证二者不分离 - 对高频更新表，避免在触发器里做复杂计算或远程调用，否则拖慢主 DML；可改为异步消费
binlog（如用 Debezium）
别在 MyISAM 上折腾“模拟行级追踪”——视图、应用层拦截、定时比对 checksum 都不可靠。只要表还是 MyISAM，任何方案都会在并发、崩溃、或误操作时漏掉变更。迁移前先确认主键存在、NULL 值合规、磁盘空间充足，再执行 ALTER TABLE t ENGINE = InnoDB。这一步绕不开。
