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，而不是留着字段空着。
