FLUSH LOGS 卡住写入是因为需获取全局锁 LOCK_log，阻塞所有 DML/DDL，高并发下可达数百毫秒至秒级；应避免业务高峰执行，调大 max_binlog_size、启用 binlog_order_commits、用 mysqladmin 替代 SQL 命令，并优化 sync_binlog 与磁盘 IO 策略。
为什么 FLUSH LOGS 会卡住写入
执行 FLUSH LOGS 时，MySQL 会强制关闭当前 binlog 文件并新建一个，这个过程需要获取全局锁（LOCK_log），期间所有 DML 和 DDL 都会被阻塞，直到新日志文件就绪。尤其在高并发写入场景下，这个“瞬间”可能长达数百毫秒甚至秒级——你看到的慢查询、连接堆积，往往就卡在这儿。
实操建议：
- 避免在业务高峰手动执行
FLUSH LOGS；生产环境应交由自动轮转机制控制 - 检查是否误配了
max_binlog_size过小（如1M），导致频繁触发轮转；建议设为100M～1G，视单日 binlog 量而定 - 确认未启用
binlog_order_commits=OFF（MySQL 8.0+ 默认 ON），否则轮转时可能加剧事务提交延迟
expire_logs_days 不生效？先查 binlog_expire_logs_seconds
MySQL 5.7 引入 expire_logs_days，但 8.0.11+ 已将其标记为 deprecated，实际生效的是 binlog_expire_logs_seconds（单位秒）。如果发现过期日志没被清理，大概率是后者覆盖了前者，且默认值为 2592000（30 天）。
实操建议：
- 用
SHOW VARIABLES LIKE 'binlog_expire_logs_seconds';确认真实配置 - 设置时优先用新参数：
SET PERSIST binlog_expire_logs_seconds = 86400;（保留 1 天） - 注意：该参数只控制自动清理时机，不改变轮转行为；清理动作本身在下次
FLUSH LOGS或定时器触发时执行，不实时
用 mysqladmin flush-logs 替代 SQL 命令更安全
直接在客户端执行 FLUSH LOGS 是 SQL 语句，走常规连接路径，容易和长事务、MDL 锁冲突；而 mysqladmin flush-logs 是客户端工具，底层调用的是 MySQL 的管理协议，绕过部分 SQL 层锁逻辑，响应更快、阻塞更轻。
实操建议：
- 运维脚本中统一用
mysqladmin -u root -p flush-logs，别写成mysql -e "FLUSH LOGS" - 加
-S /tmp/mysql.sock指定 socket 路径，避免走 TCP 导致额外延迟 - 若需静默执行，加
-f参数跳过确认，但务必确保调用时机可控（比如配合systemd timer固定在低峰）
rotate 时磁盘 IO 突增？关掉 sync_binlog=1 不现实，改用 sync_binlog=1000 折中
每条事务都刷盘（sync_binlog=1）能保数据安全，但轮转瞬间会把积压的 binlog 缓冲区一次性落盘，IO 尖峰明显。而设为 0 又太危险——宕机可能丢整个 binlog 文件。
实操建议：
- 折中方案：设
sync_binlog=1000，即每 1000 条事务同步一次；既降低 IO 频率，又不至于丢失太多 - 搭配
innodb_flush_log_at_trx_commit=2使用，进一步缓解日志写入压力（注意：这会牺牲部分崩溃安全性） - 观察
SHOW GLOBAL STATUS LIKE 'Binlog_cache_use';和Binlog_cache_disk_use，若后者非零，说明 binlog 缓存溢出到磁盘临时文件，此时增大binlog_cache_size（如从默认32K提到1M）比硬扛轮转更有效
真正难处理的是 binlog 和 relay log 共享同一块磁盘，轮转时 IO 竞争无法避免；物理隔离才是根治点，但多数人卡在预算和运维惯性上。
