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 还有存在价值吗
不是“不用”，而是明确知道代价后谨慎选用：
纯静态只读表（如省份字典、配置项），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，也等于没用。
