慢SQL日志一天吞65G磁盘？加了动态采样率降到1.2G
凌晨两点，报警群里炸了。 "订单服务三台机器磁盘使用率全部超过 95%，其中一台已经 99%。下单接口开始超时，用户付不了款了。" 我迷迷糊糊掏出手机看了一眼，心头一紧。这是线上大促前夕，每秒几千单的交易量，磁盘满了意味着日志写不进去、服务随时可能挂掉。 赶紧登上服务器一看，/data/logs 目录占了整整 230G。顺着 du 一层层摸下去： /data/logs/slow-sql/ ├── 2026-06-20.log 68G ├── 2026-06-19.log 61G ├── 2026-06-18.log 55G └── ... 好家伙，慢 SQL 日志每天能写六七十 G。 我们慢 SQL 阈值设的 500ms，全量记录每一条慢查询的完整 SQL、执行时间、调用堆栈。业务高峰期每秒几千个查询，大促期间并发一上来，哪怕只有 5% 的 SQL 超过 500ms，每天就是几百万条记录。 那一刻我突然意识到一个问题：我们到底需要记录这么多慢 SQL 吗？ 一、全量记录的代价，不光是磁盘 回过头来看，全量慢 SQL 日志的代价远比磁盘空间要大： 磁盘 IO 争抢。 每一条慢 SQL....
