MyISAM 不支持事务，禁止用于需 ACID 的场景；InnoDB 是默认且唯一合理选择，但需正确管理 autocommit 和显式事务边界；MEMORY、Archive、CSV 等引擎均不支持事务，仅适用于特定非事务场景。

MyISAM 不支持事务，别在需要 ACID 的场景用它

如果你的业务要求数据一致性（比如订单创建必须同时写入订单表和库存表），MyISAM 直接排除。它不支持 COMMIT、ROLLBACK，也没有行级锁，所有写操作都是表级锁定。一旦有长事务或并发更新，整个表就卡住。

常见错误现象：START TRANSACTION 执行成功但后续 ROLLBACK 无效；SELECT @@autocommit 返回 1，但手动 COMMIT 后数据仍丢失。

• MyISAM 适合只读或读多写少的报表类场景，比如日志归档表、配置缓存表
• 即使表结构简单、数据量小，只要逻辑上存在“要么全成功、要么全失败”的依赖，就不能选 MyISAM
• MySQL 8.0 默认存储引擎已是 InnoDB，新库新建表不显式指定引擎时自动使用它

InnoDB 是默认且最稳妥的选择，但要注意隐式事务行为

InnoDB 支持完整 ACID、行级锁、外键、MVCC，是绝大多数 OLTP 场景的唯一合理选项。但它不是“开箱即用就完全安全”——它的事务行为高度依赖 autocommit 设置。

典型陷阱：autocommit=1（默认）下，每条 INSERT/UPDATE/DELETE 都是独立事务，无法和前一条语句一起回滚；而 autocommit=0 下，不显式 COMMIT 或 ROLLBACK，连接断开时会自动回滚，容易漏处理。

• 应用层控制事务时，建议显式执行 SET autocommit = 0，再用 BEGIN / COMMIT / ROLLBACK 管理边界
• 避免在存储过程中混合使用 autocommit=1 和手动事务，容易因异常退出导致部分提交
• InnoDB 的 UNIQUE 约束检查在语句执行时触发，不是事务提交时，所以违反约束会立刻报错，不等 COMMIT

Memory 引擎只存内存，重启即丢，不能用于事务持久化

MEMORY 引擎把所有数据放在 RAM 中，查询极快，但完全不支持事务：没有 ROLLBACK 能力，START TRANSACTION 会静默忽略，COMMIT 也不报错但无实际效果。

它常被误用作“临时高速缓存”，结果服务重启后数据全空，上游没做兜底就直接报错。更隐蔽的问题是，MEMORY 表的 TEXT 和 BLOB 类型不支持，且表大小受 max_heap_table_size 限制，超限插入会失败。

• 仅适用于生命周期明确、可随时重建的临时中间结果，比如 ETL 过程中的聚合暂存
• 如果要用它模拟事务行为（比如先写再校验），必须在应用层自己实现状态快照和恢复逻辑
• 不要把它当 InnoDB 的轻量替代品——二者设计目标完全不同

其他引擎如 Archive、CSV 基本不参与事务流程

Archive 只支持 INSERT 和 SELECT，没有索引、不支持 UPDATE/DELETE，自然也无法参与事务控制；CSV 引擎直接映射为文本文件，所有操作都绕过 MySQL 的事务日志机制。

它们的存在意义是数据交换或归档压缩，不是在线业务承载。强行在这些表上执行 START TRANSACTION 不报错，但后续任何写操作都会立即落盘，ROLLBACK 完全无效。

• 导出/导入场景可用 CSV，但别把它当正式业务表
• Archive 适合存储审计日志、点击流等只追加、极少查询的历史数据
• 跨引擎 JOIN 或事务中混用不同引擎表时，MySQL 只对 InnoDB 表保证事务性，其余引擎变更不可回滚

事务不是开关，而是引擎、SQL 模式、应用逻辑三层咬合的结果。哪怕用了 InnoDB，如果应用没正确管理 autocommit 和异常路径，照样会出现数据不一致。最常被忽略的是连接池复用场景下，前一个请求留下的 autocommit=0 状态可能污染下一个请求。