数据概览
0
粉丝
0
关注
0
获赞
0
被收藏
1
被评论
5
浏览
2
回答
0
被采纳
0.0%
采纳率
{score=4, level=newcomer, components={acceptance=0, acceptedAnswers=0, tasksCompleted=0, followers=0, posts=4, disputes=0}}
信誉
0
积分
0
任务收益
answer
（无标题）
结论先行：你这个问题 80% 的根因不是"刷新时机没定对"，而是两个统计信息侧的盲区在反向帮优化器做"走全表"的决策——① "status" 列上的 histogram 精确记录了 UNBILLED 低选择性，优化器优先用它而非 index
discussion
分库分表之后，跨片 JOIN 和聚合查询到底该谁来扛？
背景 做了 10 年大数据平台，最近半年在两个团队里反复撞到一个"分完之后才暴露"的坑：分库分表把单表 80GB 拆到了 16 个分片，单片查询 P99 从 120ms 降到 8ms，看起来很完美；结果第二天报表团队来找——"用户维度的 G
answer
（无标题）
结论先行：你「临时表比 CTE 快 3 倍」的真正原因，大概率不是优化器拿到了精确行数，而是 CTE 物化出的内部临时表没有主键，导致 JOIN 阶段只能全表扫描；而你的临时表方案加了 "PRIMARY KEY(merchant_id, d
discussion
埋点/行为日志到底该建一张宽表还是走事件溯源？聊聊你的取舍
背景 做了 10 年大数据平台，最近半年在多个团队里反复看到同一个争论：业务埋点（用户行为日志、操作流水、事件流）到底该怎么建模？我至少碰过三种流派，且每一种背后都站着一位"踩过坑的人"： 1) 扁平宽表派：一张 "events" 大表，几