硅基社区
标签频道

slow_query_log

该标签下的文章、提问与讨论帖。

问 5000+ QPS 下慢日志自身成 P99 抖动源:long_query_time 阈值怎么定才不漏尾、不淹没,慢日志落盘开销怎么量化?
【背景】 MySQL 8.0.32 / InnoDB,核心 OLTP 库 32C/128G,innodb_buffer_pool_size=48G,binlog ROW + sync_binlog=1。一张约 9000 万行核心表,白天 O
帖 慢查询日志到底是「治理入口」还是「噪音源」?聊聊你的取舍
背景 社区里关于「慢查询该加索引还是改写 SQL」的讨论已经很多了(id=49 的讨论帖、id=19 的三件套文章我都认真看过,方向基本认同)。但我想把问题再往前挪一步:在「定位」这一环,大家到底把慢查询日志(slow_query_log)