跨行事务处理必须用InnoDB，MyISAM不支持事务、无原子性保障、无崩溃恢复、无行级锁与隔离级别，无法满足多行/多表“全成或全败”需求。
跨行事务处理必须用 InnoDB，MyISAM 根本不支持事务——它连 BEGIN、COMMIT、ROLLBACK 都会直接忽略。
MyISAM 对事务语句完全无感知
在 MyISAM 表上执行 BEGIN 或 START TRANSACTION，MySQL 不报错也不生效；后续的 UPDATE 和 INSERT 仍是立即落盘。哪怕你写了 ROLLBACK，也不会撤销任何已执行语句。
- 常见错误现象：
UPDATE orders SET status = 'paid' WHERE id = 123;执行一半崩溃 → 订单状态已改，但关联的日志表没写入，数据永远不一致 - 应用层 try-catch + 补偿逻辑？网络超时或进程崩溃时，补偿代码根本没机会运行
- MyISAM 的
AUTO_INCREMENT不受事务保护：事务回滚后，自增值仍递增，造成 ID 空洞且不可逆
InnoDB 的 redo log + undo log 是跨行原子性的底层保障
跨行操作（比如扣库存 + 写订单 + 更新用户积分）要“全成或全败”，靠的是 InnoDB 在内存中维护的两套日志：
-
redo log记录“物理变更”：确保已COMMIT的数据即使没刷盘也能恢复 -
undo log记录“逻辑前镜像”：让ROLLBACK能精准撤回未提交的多行修改 - 服务器异常断电后重启，InnoDB 自动前滚已提交事务、回滚未提交事务，全程无需人工干预
行级锁只在事务内真正起效，而 MyISAM 连这个前提都没有
事务不是加个 BEGIN 就完事——它必须和锁机制协同。InnoDB 的行级锁（如 SELECT ... FOR UPDATE）只在事务上下文中才有意义：
- 跨行更新时，
UPDATE stock SET qty = qty - 1 WHERE sku = 'A'; UPDATE orders SET status = 'confirmed' WHERE order_id = 999;这两行在同一个事务里，才能保证中间状态对外不可见 - MyISAM 没有事务上下文，
FOR UPDATE语法直接报错；它的锁是刚性的表级锁，和“跨行一致性”毫无关系 - 没有事务隔离级别（如
REPEATABLE READ），并发读取时可能看到半更新的中间态数据
容易被忽略的关键点：事务不是可选功能，而是存储引擎的硬性能力边界
你无法通过应用层“模拟”出 MyISAM 上的跨行事务。因为崩溃恢复、锁生命周期、MVCC 可见性判断，全部由引擎内核控制。InnoDB 把这些能力封装进 ib_logfile0、ibdata1 和 Buffer Pool；MyISAM 的 .MYD 和 .MYI 文件根本不存这些元信息。一旦业务出现“多表/多行必须一起成功”的需求，换引擎是唯一路径——不是优化，是必要条件。
