log_sys->mutex是InnoDB保护redo log buffer分配、拷贝、LSN更新与刷盘协调的全局单点锁，所有事务（哪怕只改一行）都必须串行争抢；调大innodb_log_file_size无效，应增大innodb_log_buffer_size并设innodb_flush_log_at_trx_commit=2缓解争用。
log_sys->mutex 是什么，为什么它卡住所有写入
这把锁不是“可选优化项”，而是 InnoDB 事务日志路径上绕不开的临界区入口。只要事务产生 redo（哪怕只改一个字段），就必须抢 log_sys->mutex：分配 buffer 空间 → 拷贝日志内容 → 更新内存 LSN → 判断是否刷盘。它不按事务拆分、不按页隔离，是全局单点。QPS 超过 2000 后，SHOW ENGINE INNODB STATUS 里大量线程会卡在 log_write_up_to 或 log_flush_up_to，OS WAIT ARRAY 显示自旋等待该 mutex。
哪些参数调整能直接减少 log_sys->mutex 争抢次数
核心思路是让每次持锁时间变短、触发频率变低，而不是“加更多锁”或“换算法”——InnoDB 5.7/8.0 都没提供无锁日志路径。
-
innodb_log_buffer_size设为 64M（默认 16M）：buffer 小 → 容易满 → flush 更频繁 → mutex 抢得更勤；观察Innodb_log_waits是否持续 > 0，是就说明 buffer 不够用 -
innodb_flush_log_at_trx_commit = 2：日志写入 OS 缓存即返回，后台每秒统一刷盘；吞吐可提升 3–10 倍，但崩溃最多丢 1 秒数据 - 避免在事务中做耗时操作（如远程调用、JSON 大字段拼接），缩短事务生命周期，也就压缩了日志写入窗口
为什么调大 innodb_log_file_size 对锁竞争无效
innodb_log_file_size 控制的是磁盘上 redo 文件大小，影响 checkpoint 频率和 crash recovery 时间，但完全不参与 log_sys->mutex 的争用路径。它太小 → checkpoint 太频繁 → 脏页刷盘压力大 → 反向拖慢 log write；但它增大后，并不会减少 mutex 抢占次数，甚至可能因单次刷盘量变大，延长后台 io_thread 工作时间，间接加重锁等待。
真正要算的是写入吞吐与 buffer 容量的匹配度：用 SHOW GLOBAL STATUS LIKE 'Innodb_os_log_written' 每 30 秒采样，算出每秒平均写入字节数，再按该值 × 60 × 2 来反推合理 innodb_log_buffer_size，而非盲目调大日志文件。
批量插入时最容易忽略的 buffer 匹配问题
Java 应用用 executeBatch() 插入 1 万行，若 innodb_log_buffer_size 还是默认 16MB，很可能每个 batch 都触发一次 buffer flush，导致事务提交变慢——因为大事务产生的 redo 日志先填满 buffer，再强制刷盘，全程被 mutex 卡住。
关键点在于：innodb_log_buffer_size 只缓存事务内产生的 redo 日志，不缓存数据页本身；它影响的是“事务执行中”的日志生成效率，而非持久性保障。对单事务写入量 > 1MB 的场景（如含 BLOB/TEXT 的 UPDATE、大批量 INSERT），必须同步调大该值，否则 buffer 成了隐式性能断点。
