mysql 8.0+ 默认innodb引擎保障事务一致性，需显式声明engine=innodb、设innodb_flush_log_at_trx_commit=1和sync_binlog=1，配row格式binlog、主键约束及合理隔离级别，并以应用层事务+幂等+补偿为主。
MySQL 默认存储引擎如何影响数据一致性
MySQL 8.0+ 默认使用 InnoDB，它天然支持事务、行级锁和崩溃恢复，是保障数据一致性的基础。如果误用 MyISAM（不支持事务、无崩溃安全写入），哪怕加了 COMMIT 也毫无意义——INSERT 或 UPDATE 中途失败会导致表处于半更新状态，且无法回滚。
检查当前表引擎：
SHOW CREATE TABLE t1;确认
ENGINE=InnoDB；若为 MyISAM，需显式转换：ALTER TABLE t1 ENGINE = InnoDB;
- 不要依赖 MySQL 配置项
default-storage-engine全局设置，建表时务必显式声明ENGINE=InnoDB -
innodb_flush_log_at_trx_commit=1（默认）才能保证每次COMMIT都落盘，设为2或0会丢失最近最多 1 秒的事务 -
sync_binlog=1配合innodb_flush_log_at_trx_commit=1，才能在主从复制中避免“主库写成功但从库没收到”导致的一致性断裂
外键约束是否真能保障业务一致性
外键（FOREIGN KEY）只校验引用完整性（如子表 user_id 必须存在于父表），但不覆盖业务逻辑一致性。例如：用户余额扣减、订单状态流转、库存预占释放等，外键完全无能为力。
更关键的是，InnoDB 外键在高并发下可能成为性能瓶颈，且部分分库分表中间件（如 ShardingSphere、MyCat）根本不支持跨节点外键。
- 外键应仅用于强关联的静态元数据（如
status_type表），避免用于高频变更的业务实体（如订单与商品） - 真正需要一致性的地方，靠应用层事务 + 幂等设计 + 补偿任务，而不是依赖外键自动拒绝插入
- 删除父记录前，必须先处理子记录（或设
ON DELETE CASCADE），但后者在大表上易引发长事务锁表，慎用
READ COMMITTED 和 REPEATABLE READ 隔离级别怎么选
MySQL 默认隔离级别是 REPEATABLE READ，它通过间隙锁（Gap Lock）防止幻读，但也因此更容易死锁；而 READ COMMITTED 只用行锁，幻读可能发生，但并发冲突少得多。
多数 Web 应用其实不需要严格的可重复读：同一事务内两次 SELECT 看到不同结果，只要业务逻辑能容忍（比如查订单列表后刷新看到新订单），就该优先选 READ COMMITTED。
- 电商下单场景中，若用
REPEATABLE READ对库存做SELECT ... FOR UPDATE，可能因间隙锁锁住整个价格区间，导致无关商品也被阻塞 -
READ COMMITTED下，UPDATE语句只锁定实际命中的行，不锁间隙，适合高并发更新场景 - 切换前需确认应用未依赖
REPEATABLE READ的“事务内快照不变”特性（如某些报表类逻辑）
binlog 格式对一致性的影响常被低估
binlog_format 设为 STATEMENT 时，MySQL 只记录原始 SQL，一旦语句含函数（如 NOW()、UUID()、USER()）或不确定排序（ORDER BY 缺失），主从执行结果必然不一致。现在默认是 ROW，但仍有陷阱：
-
ROW模式下，如果表没有主键或唯一非空索引，UPDATE/DELETE在从库可能匹配多行或零行，造成数据漂移 -
MIXED不是万能解法——它由 MySQL 自动判断语句是否安全，但判断逻辑复杂，出问题时难以追溯 - 所有线上表必须有主键；否则
ALTER TABLE ... ADD PRIMARY KEY(id)是刚需，不是优化项
一致性不是靠单点配置实现的，而是引擎选择、隔离级别、binlog 模式、主键约束、应用事务边界这五者咬合的结果。漏掉任意一环，都可能在流量高峰或故障恢复时暴露出来。
