binlog cache溢出不会记入慢查询日志，因其发生在执行完成后、提交前，不计入Query_time；需通过binlog_cache_disk_use/binlog_cache_use>5%、performance_schema指标异常及general_log时间差综合判断。
binlog cache溢出不会直接记入慢查询日志
MySQL的慢查询日志只记录语句执行耗时（Query_time），而binlog_cache_use和binlog_cache_disk_use这类指标反映的是事务写入binlog时的内存缓冲使用情况——它发生在语句执行完成之后、提交之前，不计入Query_time。所以即使某条UPDATE因为binlog_cache_size太小被迫刷盘到磁盘临时文件，慢日志里也看不到它“变慢”，只会看到一条普通耗时、但实际执行卡顿的SQL。
怎么确认是不是binlog cache在拖慢事务
关键看两个状态变量的比值，不是看单条SQL的执行计划：
-
SHOW GLOBAL STATUS LIKE 'binlog_cache_use';—— 表示总共有多少次事务成功用上了内存cache -
SHOW GLOBAL STATUS LIKE 'binlog_cache_disk_use';—— 表示有多少次被迫用了磁盘临时文件（即溢出）
如果binlog_cache_disk_use / binlog_cache_use > 0.05（即5%以上事务都溢出），基本可以判定binlog cache配置偏小，尤其在批量INSERT/UPDATE场景下会显著拉长事务提交时间。
补充验证方式：
- 查
performance_schema.events_statements_summary_by_digest中对应SQL的SUM_LOCK_TIME或SUM_ROWS_AFFECTED是否异常高，但SUM_TIMER_WAIT没同步升高——说明耗时不在执行阶段，而在提交环节 - 开启
general_log（仅临时、低流量时段）观察同一条语句的“执行完成”和“返回客户端”之间是否存在明显gap
如何调优binlog cache相关参数
核心就两个参数，且**必须在mysqld启动时设置，无法动态修改**：
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
-
binlog_cache_size：每个客户端事务独享的内存buffer，默认32KB。对含大量行变更的事务，建议按单事务平均binlog大小的1.5倍设，比如预估单事务产生800KB binlog，则设为1310720（1.25MB） -
max_binlog_cache_size：单事务允许使用的最大binlog cache上限，默认16MB。这个值不能低于binlog_cache_size，但也不宜设得过大，否则可能被大事务长期占住内存
注意：binlog_cache_size是每个连接独立分配的，不是全局共享。连接数多时，盲目调大会吃掉大量内存；但设得太小又会导致频繁磁盘落盘，IO毛刺明显。
容易被忽略的关联点：autocommit=0 + 长事务
binlog cache只在事务模式下起作用。如果你的应用显式执行了SET autocommit = 0，然后执行一个持续几秒的大查询+大更新，那整个事务生命周期内binlog cache都会被占用，直到COMMIT。这时候即使binlog_cache_size够用，也可能因事务过长导致其他并发事务排队等待cache资源。
所以排查时务必确认：
- 慢SQL是否出现在显式事务块中（
BEGIN/START TRANSACTION） - 应用层是否有未及时
COMMIT或ROLLBACK的悬挂事务 -
information_schema.INNODB_TRX里是否存在trx_started很早但trx_state = 'RUNNING'的长事务
真正难定位的，往往不是参数设错，而是事务边界不清+cache资源被长事务锁死——这种问题在慢日志里完全隐身，只能靠状态变量+事务视图交叉印证。
