myisam不支持事务，导致无原子性保障、必然丢失更新、无法规避脏读/不可重复读/幻读、备份易逻辑断裂，且存在静默不一致风险。
MyISAM不支持事务，意味着没有原子性保障
一旦业务逻辑涉及多步写操作（比如“扣库存 + 写订单 + 记日志”），MyISAM 无法保证它们要么全成功、要么全失败。某一步出错（如网络中断、磁盘满、应用崩溃），前面已执行的 UPDATE 或 INSERT 会直接落库，后续步骤无法回滚——结果就是数据库状态残缺、业务语义断裂。
并发更新时丢失修改（Lost Update）几乎必然发生
两个请求同时读取同一行（如商品库存=10），各自减1后写回，最终库存变成9而不是预期的8。MyISAM 没有行级锁机制，也不提供 MVCC 或事务快照，UPDATE 是覆盖式写入。即使加了 SELECT ... FOR UPDATE，MyISAM 也只支持表级锁，锁粒度粗、阻塞严重，且无法在事务中协调一致性。
无法规避脏读、不可重复读、幻读等隔离问题
因为 MyISAM 根本没有事务隔离的概念：它不维护 undo log，不生成事务版本，也不做读写冲突检测。任何并发读写都可能看到中间态或不一致结果。例如财务对账时，一个脚本刚 INSERT 一笔流水，另一个脚本立刻 SELECT SUM() 就可能漏掉它（无提交语义）；或者两次 SELECT COUNT(*) 同一条件，结果不同（无快照保证）。
备份与恢复场景下数据逻辑断裂风险高
MyISAM 的 mysqldump 默认不带 --single-transaction（该参数对 MyISAM 无效），备份过程无法获得一致性快照。若备份中途有写入，导出的 SQL 可能包含部分更新后的表和部分未更新的表，还原后业务主键冲突、外键缺失、状态错位等问题频发。而 InnoDB 在相同命令下可利用 MVCC 提供一致性视图。
真正棘手的不是“报错”，而是“静默不一致”——数据看起来都存在、校验和也对，但业务流转已悄然断裂。换引擎前务必检查所有跨表更新、幂等逻辑、补偿机制是否还成立。
