事务提交后数据不一定写入磁盘，取决于innodb_flush_log_at_trx_commit配置：0或2可能丢失最多1秒事务，1（推荐）每次提交都fsync保证持久性。
事务提交后数据一定写入磁盘了吗？
不一定。MySQL 的持久性（Durability）不等于“立即落盘”，而是指事务一旦 COMMIT 成功，其修改在数据库崩溃后仍能恢复——这依赖于 innodb_flush_log_at_trx_commit 参数和 WAL（Write-Ahead Logging）机制。
默认值为 1：每次事务提交时，redo log 必须刷到磁盘（fsync），保证崩溃不丢事务；设为 0 或 2 会牺牲部分持久性换取性能，但可能丢失最近 1 秒内的提交。
-
0：日志只写入 OS 缓存，每秒fsync一次 → 崩溃最多丢 1 秒事务 -
2：日志写入 OS 缓存并刷新到文件系统 page cache，但不强制fsync→ 依赖 OS 稳定性，断电可能丢日志 -
1（推荐生产环境）：每次COMMIT都fsyncredo log → 持久性最强，但 I/O 开销最大
一致性（Consistency）是数据库自动保证的吗？
不是。MySQL 的 ACID 中 “C” 不是内建约束，而是由用户定义的规则 + 数据库机制共同维护的结果。InnoDB 只负责执行你写的 SQL 和已启用的约束，不会主动校验业务逻辑是否自洽。
例如：CHECK 约束（MySQL 8.0.16+ 支持）、FOREIGN KEY、唯一索引、非空约束等，能拦截明显违规写入；但像“账户余额不能为负”或“转账前后总额不变”这类逻辑，必须靠应用层校验 + 正确使用事务包裹。
- 外键失效（
foreign_key_checks=OFF）或禁用约束会导致一致性被绕过 -
INSERT ... ON DUPLICATE KEY UPDATE若未谨慎设计，可能掩盖本该报错的数据冲突 - 长事务中读取未提交变更（如误用
READ UNCOMMITTED）会让应用基于脏数据做判断，间接破坏一致性
为什么开了事务还出现数据不一致？
常见原因是隔离级别与并发操作配合不当，或事务边界没包住全部相关操作。InnoDB 默认隔离级别是 REPEATABLE READ，但它不解决所有并发问题。
比如两个事务同时读取同一行余额、各自扣减后再写回（典型的“读-改-写”竞争），即使加了事务，也会发生覆盖写入，导致最终结果错误——这不是事务失效，而是缺少行锁或乐观锁控制。
- 显式加锁：用
SELECT ... FOR UPDATE在读取时获取排他锁，阻塞其他事务修改 - 避免在事务中调用外部服务（如 HTTP 请求），超时或重试可能导致重复提交或状态错乱
- 不要在事务里做耗时计算或循环插入大量数据，容易触发锁等待超时（
Lock wait timeout exceeded）
START TRANSACTION; SELECT balance FROM accounts WHERE id = 1 FOR UPDATE; -- 此时其他事务对 id=1 的 FOR UPDATE 会被阻塞 UPDATE accounts SET balance = balance - 100 WHERE id = 1; COMMIT;
binlog 和 redo log 如何协同保障持久性？
MySQL 采用“双日志”机制：InnoDB 的 redo log 保证崩溃恢复（crash-safe），Server 层的 binlog 用于主从复制和 PITR（Point-in-Time Recovery）。两者内容不同、格式不同、刷盘时机也不同。
为了保证主从一致和崩溃后可恢复，MySQL 使用 XA 两阶段提交（2PC）协调它们的写入顺序：先写 redo log（prepare 阶段），再写 binlog，最后写 redo log（commit 阶段）。如果 crash 发生在中间，恢复时会根据 redo log 中的 prepare 状态去 binlog 查找对应 XID，决定回滚还是提交。
- 若
sync_binlog=1未开启，binlog 可能只写入 OS cache，主机断电时 binlog 丢失 → 主从数据不一致 -
innodb_support_xa=ON（5.7.7+ 默认启用）必须打开，否则无法正确协调两阶段提交 - 物理备份（如 xtrabackup）依赖
redo log，逻辑备份（mysqldump）依赖binlog位置，二者不可互相替代
事务的持久性有明确的配置杠杆可调，一致性则高度依赖你怎么写 SQL、设什么约束、以及是否把所有关联操作放进同一个事务。最容易被忽略的是：把业务规则当成数据库能力，或者以为只要用了 BEGIN...COMMIT 就万事大吉。
