myisam不支持事务，无acid保障；innodb通过事务、约束和正确配置实现一致性，需开启事务、启用外键、使用row格式binlog并设置flush参数。
MyISAM 不支持事务，谈不了 ACID
mysql 5.5 之前默认用 MyISAM，但它压根没有事务机制：ROLLBACK 无效，COMMIT 是空操作，START TRANSACTION 也起不到隔离作用。一旦写入中途崩溃，很可能留下半截数据或索引错乱——这不是“一致性弱”，是根本没提供保障。
常见错误现象包括：
- 执行多条
UPDATE后断电，部分行更新成功、部分未更新，应用层无法回滚 -
REPAIR table频繁出现，因为崩溃后索引页和数据页不同步 - 并发
INSERT+select时读到未提交的中间状态（虽无事务，但连基本的读一致性都难保证）
InnoDB 如何实现 ACID 中的 C（一致性）
InnoDB 的一致性不是靠引擎“自动维持”的，而是依赖事务 + 约束 + 正确使用方式共同达成。它本身只保证原子性（A）、隔离性（I）、持久性（D），而 C（一致性）是上层逻辑的结果。
关键实操点：
- 必须开启事务：
BEGIN/START TRANSACTION，否则每条语句自动提交，失去原子组合能力 - 外键约束要显式启用：
forEIGN_KEY_CHECKS = 1，否则INSERT INTO child可能插入孤儿记录 - 唯一索引冲突会触发
Error 1062，但若应用忽略该错误并继续执行后续逻辑，一致性就破了 - 避免在事务中调用不支持事务的外部操作（如写文件、发 http 请求），这类操作失败无法回滚
READ COMMITTED 和 REPEATABLE READ 对一致性的实际影响
InnoDB 默认隔离级别是 REPEATABLE READ，但它不是“绝对可重复读”——幻读仍可能发生（通过 INSERT 或 UPDATE ... WHERE 新增匹配行）。而 READ COMMITTED 每次 SELECT 都读最新已提交版本，看似更“实时”，却可能让同一事务内多次查询结果不一致。
典型场景对比：
- 资金转账：用
REPEATABLE READ可防止 A 查余额后 B 转走钱、A 再查变少的问题；但若需防止幻读（如统计未处理订单数），得加SELECT ... FOR UPDATE - 报表导出：用
READ COMMITTED可能导出过程中数据边查边变，总数对不上；此时应切到REPEATABLE READ或显式加事务快照 - 参数设置：
SET session TRANSACTION ISOLATION LEVEL READ COMMITTED只影响当前会话，别误设成全局（GLOBAL）导致其他业务异常
binlog 格式与存储引擎协同决定最终一致性
InnoDB 自身的 redo log 保证崩溃恢复，但主从复制靠的是 binlog。如果 binlog_format = STATEMENT，而 SQL 里用了 NOW()、UUID()、INSERT ... SELECT 等非确定性语句，从库回放结果可能和主库不一致。
真正落地时要注意：
- 生产环境强烈建议设为
binlog_format = ROW，它记录每行变更，和 InnoDB 的行级锁、MVCC 天然匹配 - 即使用了
ROW格式，如果主库用MyISAM表混在事务里，binlog 仍可能不一致（MyISAM 不参与事务，但会被写入 binlog） -
innodb_flush_log_at_trx_commit = 1和sync_binlog = 1必须同时开启，否则 crash 后可能丢事务（redo log 丢了或 binlog 丢了）
一致性从来不是单点配置能解决的事，它卡在事务边界、SQL 写法、复制链路、甚至应用重试逻辑里。最容易被忽略的是：把约束交给数据库做，比在应用里 if-else 判断可靠得多；但前提是，你得真去建那个 UNIQUE KEY，而不是留着字段空着。