MySQL 事务提交时是否写 redo log 由 innodb_flush_log_at_trx_commit 参数控制：0（仅写 buffer，每秒刷盘）、1（每次 commit 都 fsync，最安全）、2（写入 page cache 后返回）。
事务提交时，MySQL 怎么决定要不要写 redo log
redo log 不是「事务一提交就立刻刷盘」，而是由 innodb_flush_log_at_trx_commit 参数控制。它的取值直接影响事务的持久性与性能：
-
0：事务提交时不写日志到磁盘，只写到 log buffer；每秒由后台线程刷一次 —— 崩溃可能丢一秒数据 -
1（默认）：每次COMMIT都调用fsync()刷盘 —— 最安全，但 IO 开销最大 -
2：写入 OS page cache 即返回，不强制fsync()；依赖 OS 定期刷盘 —— 崩溃可能丢未刷盘的数据，但比 0 更可靠
线上 OLTP 系统通常设为 1；若能接受极小概率丢事务（如日志类场景），可设为 2。注意：设为 0 时即使 sync_binlog=1，binlog 和 redo 也不一致，主从可能出错。
SELECT ... FOR UPDATE 在可重复读下到底锁哪些行
在 REPEATABLE READ 隔离级别下，SELECT ... FOR UPDATE 不只是锁住扫描到的索引记录，还会加间隙锁（gap lock）或临键锁（next-key lock），防止幻读。具体锁范围取决于 WHERE 条件是否命中索引、是否唯一：
- WHERE 条件命中唯一索引且等值查询（如
id = 10）→ 只锁该记录（record lock） - WHERE 条件命中非唯一索引或范围查询（如
age > 25）→ 加 next-key lock（record + gap），锁住匹配记录及前一个间隙 - WHERE 条件没走索引 → 全表扫描，对每个聚集索引记录加 record lock，并在所有间隙加 gap lock（等效于锁全表）
可通过 SELECT * FROM performance_schema.data_locks 查看当前事务持有的锁；注意：gap lock 不会阻塞普通 SELECT，但会阻塞其他事务的插入/更新。
死锁检测触发后，MySQL 怎么选 victim 回滚
InnoDB 死锁检测是主动的（每 10 秒唤醒一次检测线程），一旦发现环形等待，立即选一个事务回滚。选择依据不是「先来后到」，而是基于 transaction weight：
- weight = 修改的行数 + 事务持有的锁数量
- weight 越小的事务越容易被选为 victim
- 如果 weight 相同，则回滚更早发起的事务（即事务 ID 更小的那个）
这意味着：执行时间短、修改少、加锁少的事务反而更危险——它更容易被牺牲。所以批量更新尽量拆小、避免长事务、减少非必要锁（比如用 UPDATE ... WHERE id IN (...) 替代逐条更新）。
显式 BEGIN 后没 COMMIT，连接断开会发生什么
MySQL 默认行为是：客户端连接异常断开（如网络中断、应用 crash），服务端会自动回滚该连接上未提交的事务。这个动作由 abort_connection 触发，不依赖 autocommit 设置。
但有两个关键例外：
- 使用了
XA START的分布式事务，断连后不会自动回滚，可能留下PREPARED状态事务，需 DBA 手动处理 - 启用了
disconnect_on_expired_password或某些代理层（如 ProxySQL）未透传连接状态，可能导致事务残留
因此，应用层必须保证：所有 BEGIN 都有明确的 COMMIT 或 ROLLBACK，不能依赖断连自动清理；监控中要定期查 INFORMATION_SCHEMA.INNODB_TRX 中 trx_state = 'RUNNING' 且 trx_started 很老的事务。
