InnoDB支持事务、行级锁、外键和崩溃恢复，能保障原子性、高并发与数据一致性；MyISAM不支持事务和外键，仅用表级锁，适合读多写少的简单场景。
因为不支持事务的引擎（比如 MyISAM）在企业级场景下无法保证关键操作的原子性和数据一致性，一旦中间出错，就只能靠人工兜底——这不是运维能承受的。
事务失败时，MyISAM 会直接丢掉部分写入
比如一个订单创建过程包含「扣减库存」+「生成订单记录」+「写入支付流水」三步。用 MyISAM 时：前两步成功、第三步因网络中断失败，数据库里就留下了库存已扣但订单没生成的脏状态；而 InnoDB 会自动回滚全部操作，保持数据库始终处于一致状态。
常见错误现象：
-
INSERT INTO orders ...; UPDATE inventory SET stock = stock - 1 WHERE id = 123;执行到一半断开，查表发现库存少了但订单没建 - 应用层手动写补偿逻辑，结果补偿又失败，形成死循环或重复扣款
InnoDB 的行级锁让高并发写入不互相卡死
电商秒杀、抢券这类场景，成千上万人同时更新同一张商品表。如果用 MyISAM 的表级锁，所有更新请求必须排队等一个用户改完整张表才能轮到下一个；而 InnoDB 只锁被修改的那几行，其他人可以同时改其他商品。
性能影响很实际：
- 相同硬件下，并发写入吞吐量可差 5–10 倍
-
SHOW ENGINE INNODB STATUS\G中频繁看到lock wait timeout，基本就是表级锁在拖后腿 - 业务监控里出现大量
Lock wait timeout exceeded错误，说明锁粒度太粗
外键和崩溃恢复不是“锦上添花”，而是故障兜底线
企业系统上线后没人敢关掉外键，因为那是防止代码 bug 导致数据断裂的最后一道闸。比如用户表被删了，但订单表里还留着指向它的 user_id，InnoDB 能直接拦住这个删除操作；MyISAM 则照删不误，后面查订单就会关联出空用户。
崩溃恢复更隐蔽但致命：
- 服务器突然断电，
MyISAM表大概率损坏，需要REPAIR TABLE，期间表不可写，且修复未必成功 -
InnoDB启动时自动重放redo log，几秒内就能回到崩溃前一致状态，业务几乎无感 - 线上遇到
Table is marked as crashed错误，基本可判定该表用了非事务引擎
真正容易被忽略的是：事务不是开了 BEGIN/COMMIT 就万事大吉。隔离级别选错、长事务没及时提交、没加索引导致锁升级成表锁——这些都会让 InnoDB 失去优势。引擎只是基础，用对才是关键。
