MySQL 5.7 中的 log_sys->mutex 属于全局单点锁，负责协调日志缓冲区的分配、写入与刷盘操作，所有事务提交都必须串行竞争该锁，高并发环境下极易形成性能瓶颈；单纯增大 innodb_log_file_size 无法解决问题，建议提升 innodb_log_buffer_size 并酌情设置 innodb_flush_log_at_trx_commit=2 来降低锁争用。
您是否曾遇到这样的困境：MySQL 5.7 的并发写入性能始终无法提升，即便 CPU 和磁盘 I/O 仍有空闲，TPS 却停滞不前？如果遇到过，大概率是卡在了 log_sys 锁上。问题并非出在配置不当，而是 InnoDB 日志子系统在高并发 INSERT/UPDATE 场景下，log_sys->mutex 成为了单点争用热点——尤其是当 innodb_flush_log_at_trx_commit=1（默认）且事务提交频繁时，所有线程都必须串行排队获取该 mutex 才能执行 redo log 写入。
log_sys mutex 成为瓶颈的深层原因
这把锁保护着整个日志缓冲区（log buffer）的分配、写入和刷盘协调逻辑，它不区分事务，也不按页或段进行拆分，任何涉及日志写入的操作都必须首先抢占这把全局锁：
- 凡是修改数据的
INSERT、UPDATE、DELETE操作，都必须记录 redo 日志，从而进入 log_sys mutex 临界区 - 即使仅修改单行数据，事务也需要执行完整的日志路径：分配 log buffer → 拷贝日志内容 → 标记 LSN → 刷盘协调（当 flush_mode=1 时）
- 当 QPS 超过 2000–3000（具体取决于 CPU 核心数和磁盘延迟），
SHOW ENGINE INNODB STATUS中会频繁出现log_write_up_to或log_flush_up_to等待事件，OS WAIT ARRAY INFO显示大量线程在log_sys->mutex上自旋或挂起
innodb_flush_log_at_trx_commit=1 是诱因，而非根源
设置为 1 能够保证崩溃安全性，但会导致每次 COMMIT 都强制 fsync redo 日志，从而放大 log_sys 锁的串行效应。问题的核心不在于“是否需要持久化”，而在于“能否将刷盘任务批量交由后台线程处理”：
innodb_flush_log_at_trx_commit=2：log buffer 每秒刷一次磁盘，但事务仍写入 buffer —— 这能显著缓解 mutex 争用，代价是崩溃时最多丢失 1 秒数据innodb_flush_log_at_trx_commit=0：更为激进，完全依赖后台线程刷盘，风险更高，仅适用于非核心业务场景- 真正需要关注的是：
innodb_log_buffer_size是否设置过小（默认 16MB）。buffer 越小 → 触发 flush 越频繁 → mutex 抢占越严重。大事务或高并发场景下，建议调整为 64M 或 128M
不要指望仅靠调大 innodb_log_file_size 就能解决问题
innodb_log_file_size 控制的是 redo log 文件的大小，影响 checkpoint 频率和恢复时间，并不能缓解 log_sys mutex 争用。增大该参数可能导致单次刷盘更重，效果反而可能不佳，甚至会进一步加重 I/O 延迟对锁持有时间的拖累：
- log file 越大 → checkpoint 间隔越长 → 每次刷脏页数量越大 → 后台 io_thread 压力增加 → 反向拖累 log write 性能
- 真正影响
log_sys锁的是 log buffer 分配与刷盘调度逻辑，与文件尺寸无关 - 验证是否确实卡在此处：执行
SHOW STATUS LIKE 'Innodb_log_waits'，如果该值持续大于 0，说明 log buffer 频繁填满，buffer size 或 flush 频率已触及极限
MySQL 5.7 缺乏真正的 log mutex 拆分机制
MySQL 8.0 引入了 log_writer 和 log_flusher 线程分离，将日志写入与刷盘解耦，显著降低了 mutex 持有时间。然而 MySQL 5.7 完全依赖单个 log_sys->mutex 统一管控，所有操作路径共用同一把锁：
- 既没有 per-buffer-segment 锁，也没有 writer/flusher 分离
- 即便开启了
innodb_parallel_read_threads或调大innodb_thread_concurrency，对 log_sys 锁也毫无助益 - 唯一的绕过策略是减少单位时间内的 COMMIT 次数：合并小事务、使用批量 INSERT 代替循环单行、启用
autocommit=0并手动控制提交时机
log_sys 锁的问题具有隐蔽性——它不报错、不超时、不显式阻塞，仅表现为写入延迟突增、TPS 无法提升、CPU user% 高但 iowait 不高。最容易被忽略的一点是：当您专注于优化 SQL 或索引时，性能瓶颈早已在日志子系统内部卡死。
