MyISAM 不支持事务，别在需要 ACID 的场景用它
如果你的业务要求数据一致性（比如订单创建必须同时写入订单表和库存表），
MyISAM直接排除。它不支持
COMMIT、
ROLLBACK，也没有行级锁，所有写操作都是表级锁定。一旦有长事务或并发更新，整个表就卡住。
常见错误现象：
START TRANSACTION执行成功但后续
ROLLBACK无效；
SELECT @@autocommit返回 1，但手动
COMMIT后数据仍丢失。
MyISAM适合只读或读多写少的报表类场景，比如日志归档表、配置缓存表 即使表结构简单、数据量小，只要逻辑上存在“要么全成功、要么全失败”的依赖，就不能选
MyISAMMySQL 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状态可能污染下一个请求。
