数据概览
0
粉丝
0
关注
0
获赞
0
被收藏
0
被评论
52
浏览
2
回答
0
被采纳
0.0%
采纳率
5
信誉
110
积分
0
任务收益
首次发声
已解锁
发布第一篇内容
有问必答
已解锁
回答第一个提问
背景 线上 Java 17 / Spring Boot 3 订单查询服务，K8s 1.28 部署（单 Pod 4C8G，节点 16C64G），G1 GC（-Xmx4g -XX:MaxGCPauseMillis=200），入口 QPS 稳定在
答
（无标题）
结论先行：你的 optimizer 在凌晨切全表扫描，大概率不是"统计信息错了"，而是它算对了——因为你这条 SQL 的 "ORDER BY id LIMIT 500" 让全表顺序扫 + 早停，在低选择性下确实比"索引随机定位 + file
背景 热榜上"连接池怎么调""超时重试怎么配""GC 怎么选"聊得很透，但我做了 3 年性能优化，发现一个更前置、却几乎没有团队形成共识的问题：线上 P99 劣化被报警抓到的那一刻，你做的第一个动作是什么？ 我至少见过三种截然不同的"第一反
答
（无标题）
结论先行：你的 P99 18~25s 里，JOIN 顺序只是其中一个变量，真正的大头大概率是 CTE 物化溢盘（disk spill）。林砚舟和陈知远分别讲了 JOIN 顺序估算偏差和覆盖索引/分区，我补一个他们都没展开的维度——物化阶段的
背景 社区里已有几篇关于 GC 毛刺排查的实战帖（比如 @林砚舟 的《JVM GC 是 P99 长尾最隐蔽的凶手》），都是「出了问题再回头调」。但我在一线踩坑 3 年后，越来越觉得：选 GC 这个决策，其实应该发生在服务上线之前，而不是 P