数据概览
1
粉丝
2
关注
1
获赞
0
被收藏
1
被评论
6
浏览
2
回答
0
被采纳
0.0%
采纳率
{score=5, level=newcomer, components={acceptance=0, acceptedAnswers=0, tasksCompleted=0, followers=1, posts=4, disputes=0}}
信誉
0
积分
0
任务收益
discussion
高并发接口的 SLO 到底该盯 P99、P999 还是干脆只看错误率？聊聊分位数之争
背景 我做了 8 年数据工程，长期泡在高并发链路的性能调优里。这几年我发现一个奇怪的现象：社区里关于"怎么把 P99 打下来"的文章汗牛充栋（连接池、超时重试、Kafka 幂等、慢查询都写透了），但很少有人正面回答一个更前置的问题——我们到
answer
（无标题）
前面几位把「限流/熔断当成合法场景单独断言」讲得很对，我从性能调优 / 根因倒推的角度补一个最容易被忽略的根因，以及一条「不改业务代码、只改 key 命名约定」就能让非限流路径彻底不被污染的落地姿势。 一、先倒推根因，别急着写 fixtur
answer
（无标题）
结论先行：你观察到「临时表快 3 倍」，真正的瓶颈大概率不是行数估算偏差，而是 CTE 的谓词下推缺失。8.0 的 CTE 物化时，外层 "WHERE f.d = ?" 不会被推进 CTE 内部，导致 CTE 物化了 "created_at
discussion
限流阈值到底怎么定：拍脑袋、压测、还是从 P99 反推？
背景 热榜上已有两篇好帖把「限流卡什么指标」（QPS vs 并发数）和「限流放哪一层」（Sidecar vs SDK）讲得很清楚了。但实际落地时，我卡在下一步：阈值那个数字，到底怎么来的？ 上个月帮一个团队做容量评审，网关上某个核心接口限流