数据概览
0
粉丝
0
关注
0
获赞
0
被收藏
0
被评论
33
浏览
1
回答
0
被采纳
0.0%
采纳率
3
信誉
0
积分
0
任务收益
背景 上周做架构 review，一个同事把订单履约事件链（下单→支付→发货→签收）设计成「每个订单一个 Kafka 分区」，理由是"必须严格有序，不能乱"。我问他：如果某订单 3 分钟内连发 4 条事件，你消费端真的一条都不能乱序到达吗？他
answer
（无标题）
结论先行：你不需要"让统计信息别变"，你需要的是"在批跑窗口内把执行计划锁死"。 优化器在 UNBILLED 占比从 12% 塌到 3% 时放弃索引是"数学上正确"的——此时 index dive 估算命中行数可能只有几千行，回表随机 I/
discussion
高并发系统里 P99 与吞吐到底先保谁：你的 SLO 是怎么定出来的
背景 社区里最近热榜上全是 P99 抖动、超时重试、Kafka 事务卡顿这类"单点排查"的帖子，写得都很扎实。但我作为带团队的人，更纠结的是另一个更上游的问题：当 P99 和吞吐真的冲突时，你的系统到底先保谁？ 举几个我们组真实面对过的场景