只有InnoDB在MySQL 5.5+中真正支持完整ACID，其通过undo log保障原子性、约束与隔离性协同维护一致性、read view与next-key lock实现隔离性、redo log确保持久性。
MySQL 中哪些存储引擎真正支持完整 ACID？
只有 InnoDB 在 MySQL 5.5+ 默认启用且完整实现 ACID（原子性、一致性、隔离性、持久性）。MyISAM 不支持事务，无原子性和崩溃恢复能力；Memory 引擎数据全在内存，重启即丢，不满足持久性；Archive 仅支持 INSERT 和 SELECT，不支持事务。如果你的业务需要事务回滚、多语句一致性或故障后自动恢复，InnoDB 是唯一可靠选择。
InnoDB 的 ACID 是怎么落地的？关键机制对应什么操作
不是靠“开关”开启 ACID，而是由底层组件协同保障：
-
原子性：靠
undo log实现——执行 UPDATE 时先写 undo 记录，事务失败就用它回滚； -
一致性：由约束（
FOREIGN KEY）、触发器、以及原子性 + 隔离性共同维护，不是引擎单独保证； -
隔离性：靠
read view+next-key lock实现可重复读（RR）默认级别，避免幻读； -
持久性：靠
redo log——DML 提交前先刷盘 redo，即使 crash 也能重放恢复。
这意味着：关掉 innodb_flush_log_at_trx_commit=0 或设为 2，会牺牲部分持久性换性能；设为 1（默认）才真正满足 ACID 中的 D。
什么时候不该用 InnoDB？MyISAM 还有存在价值吗
不是“不用”，而是明确知道代价后谨慎选用：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 纯静态只读表（如省份字典、配置项），
MyISAM的 COUNT(*) 更快（因保存了行数），但需确认无并发写入； - 全文检索早期需求（MySQL 5.6 前），
MyISAM的FULLTEXT索引更成熟，现在InnoDB已完全支持且更安全； - 超大日志类表（百亿级），若写入极密集、几乎不更新/删除，且能接受崩溃丢失最后几秒数据，可考虑关闭
innodb_doublewrite或调大innodb_log_file_size，但依然用InnoDB，而非切到MyISAM。
MyISAM 表锁 + 无崩溃恢复，在现代 OLTP 场景下基本等同于技术负债。
实际建表时怎么防踩坑？几个必须检查的配置
即使选了 InnoDB，也不代表自动获得 ACID 保障：
- 确认建表语句显式指定：
CREATE TABLE t (id INT) ENGINE=InnoDB;
不要依赖默认值，尤其跨版本迁移时； - 检查
autocommit是否开启（默认 ON），否则每个语句都是独立事务，无法手动控制回滚边界； - 避免在事务中混用引擎：
INSERT INTO innodb_t VALUES (1); INSERT INTO myisam_t VALUES (2); COMMIT;
这条 COMMIT 只对innodb_t生效，myisam_t已立即写入，无法回滚； - 监控
innodb_buffer_pool_wait_free和innodb_log_waits，持续非零说明 buffer 或 log 太小，可能拖慢提交，间接影响事务响应和持久性表现。
ACID 不是贴在引擎上的标签，而是由配置、SQL 写法、运维习惯共同决定的实际行为。最容易被忽略的是：事务边界的定义（BEGIN / COMMIT 位置）和混合引擎操作——这两点出错，哪怕用着 InnoDB，也等于没用。
