myisam不支持事务，因其设计定位为读取优化的轻量引擎，缺失redo/undo日志、事务状态管理、行级锁及崩溃恢复机制，仅支持表级锁且无acid保障能力。
MyISAM 不支持事务，根本原因在于它的设计目标和底层实现机制——它从诞生起就定位为一个轻量、快速的**面向读取优化的存储引擎**，不承担数据强一致性保障的责任。
架构上没有事务所需的日志与回滚结构
事务依赖三大核心支撑：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）——即 ACID。InnoDB 通过 redo log（重做日志） 和 undo log（回滚日志） 实现这些能力：
- redo log 保证崩溃后可恢复已提交的数据；
- undo log 记录修改前状态，用于回滚或 MVCC（多版本并发控制）；
- 事务状态、锁信息、活跃事务列表等均由内存中的事务系统统一管理。
MyISAM 完全缺失这些组件。它写入数据是直接刷盘或经 OS 缓存，没有任何“预写日志”机制，也没有事务上下文跟踪能力。一旦执行 UPDATE 或 INSERT，变更立即落物理文件，无法撤回。
锁粒度限制导致无法实现真正的事务隔离
MyISAM 只提供 表级锁（Table-level Lock）：
- 读操作加共享锁（READ LOCK），整张表只允许并发读；
- 写操作加独占锁（WRITE LOCK），阻塞所有其他读写；
- 没有行锁、间隙锁、临键锁，也无法支持可重复读（REPEATABLE READ）或读已提交（READ COMMITTED）等隔离级别。
事务的隔离性要求在并发访问中能控制“哪些数据可见、哪些不可见”，而表锁粗暴地把整个表变成串行化资源，既无法模拟事务的并发语义，也违背了 ACID 中 I 的基本前提。
无崩溃恢复能力，数据一致性无法兜底
如果 MySQL 在 MyISAM 表写入中途宕机，可能出现以下情况：
- 索引文件与数据文件不同步；
- 部分记录写入成功，部分失败，且无记录表明“这次操作属于哪个逻辑单元”；
- 必须依赖外部工具（如
myisamchk）手动修复，且修复结果不一定可靠。
而 InnoDB 的崩溃恢复流程是自动的：启动时扫描 redo log，重放已提交但未落盘的事务；再用 undo log 回滚未提交的更改。这种机制是事务型引擎的标配，MyISAM 没有设计这一路径。
历史定位决定功能取舍
MyISAM 是 MySQL 5.5 之前默认引擎，诞生于 Web 1.0 时代，典型场景是博客、论坛的静态内容展示——以 SELECT 为主、极少更新、对数据丢失容忍度相对较高。它的优势在于：
- 更小的存储开销（无事务日志、无 MVCC 元数据）；
- COUNT(*) 极快（内置行数计数器）；
- 全文索引早期仅它支持（MySQL 5.6+ InnoDB 已补齐）。
这些优势恰恰是以放弃事务能力为代价换来的。现代业务系统普遍需要订单、支付、库存扣减等强一致操作，MyISAM 已不适合担任核心数据表引擎。
所以不是“为什么不想支持”，而是“从设计第一天就没打算支持”。事务不是开关选项，而是贯穿存储引擎整个生命周期的底层契约。
