MyISAM 不支持事务，START TRANSACTION、COMMIT、ROLLBACK 无效，需应用层通过日志记录+手动补偿实现原子性与一致性，避免中间状态残留和数据不一致。
MyISAM 本身不支持事务，START TRANSACTION、COMMIT、ROLLBACK 对它完全无效——执行了也不会回滚，也不会报错，只是静默忽略。想靠 MyISAM 实现“类似事务”的效果，必须在应用层手动补全缺失的原子性与一致性保障。
MyISAM 表执行 UPDATE/INSERT 后无法回滚的典型现象
你在 MyISAM 表上运行：UPDATE orders SET status = 'paid' WHERE id = 123;，紧接着发生异常（比如下游支付回调失败），你试图执行 ROLLBACK——结果发现数据早已写入磁盘，ROLLBACK 没有任何效果。这不是 bug，是 MyISAM 的设计事实。
用应用层日志 + 手动补偿代替事务原子性
核心思路：把“一组操作”拆成可逆步骤，并记录每步状态，出错时按反向顺序人工修复。
- 先插入一条
compensation_log记录，包含操作类型（如'deduct_stock'）、目标表名（'products'）、主键值（product_id=456）、变更前值（stock=100）、预期变更量（-1）、当前状态（'pending'） - 再执行实际业务 SQL：
UPDATE products SET stock = stock - 1 WHERE id = 456; - 如果后续步骤失败（如订单创建失败），就查
compensation_log中status = 'pending'的记录，用保存的stock=100值执行覆盖更新：UPDATE products SET stock = 100 WHERE id = 456; - 成功后把日志状态改为
'done'或'compensated'
为什么不能只依赖备份或 SELECT FOR UPDATE？
MyISAM 不支持 SELECT ... FOR UPDATE，加锁只能用 LOCK TABLES，但这是表级锁，会阻塞所有并发读写；而定期 mysqldump 备份粒度太大，无法支撑秒级补偿。所以：
-
LOCK TABLES products WRITE会导致整张表卡住，高并发下不可行 - 备份恢复需要停服或至少停写，不是“补偿”，是“兜底灾难恢复”
- MyISAM 没有 undo log，没有 MVCC，无法构造快照或版本回退
MyISAM 场景下最容易被忽略的坑
很多人以为加个 TRY...CATCH 包住 SQL 就算“模拟事务”，但真正危险的是中间状态残留：比如库存扣了，订单没生成，又没记录日志，用户看到“已下单”但后台查不到记录——这种不一致不会自动修复，也不会报警，只能靠人工巡检或定时任务扫描异常状态。
更隐蔽的问题是：MyISAM 的 AUTO_INCREMENT 在崩溃后可能跳号，且不保证连续；如果补偿逻辑依赖自增 ID 做幂等判断，就会漏掉补偿项。
