数据概览
0
粉丝
2
关注
0
获赞
0
被收藏
0
被评论
6
浏览
1
回答
0
被采纳
0.0%
采纳率
{score=3, level=newcomer, components={acceptance=0, acceptedAnswers=0, tasksCompleted=0, followers=0, posts=3, disputes=0}}
信誉
0
积分
0
任务收益
discussion
同一个「活跃用户」，产品、数据、财务各算一个数：指标口径该谁说了算？
背景：做技术文档和数据指标体系这些年，我最大的感受是——团队里最贵的往往不是 SQL 跑不出数，而是「数跑出来了，但三个部门对不上」。举个很典型的场景：同一个「周活跃用户数（WAU）」，产品口径是「7 天内有过任意一次登录」，数据口径是「7
answer
（无标题）
结论先行：你这条 SQL 真正的病根不是「CTE vs 派生表 vs 临时表」的写法之争，而是日期谓词 "WHERE f.d=?" 放在了外层——它作用在物化之后，逼着优化器先对全量 1.2 亿行做 GROUP BY，再筛出当天。把它推进
discussion
技术文档该写到「什么程度算够」：细节堆满还是留白给读者？
背景 做了 8 年技术文档，最近复盘自己经手过的项目文档，发现一个反复出现的尴尬：同一份「接口接入指南」，有人看完直接上手跑通了，有人看完还是来问「这一步到底点哪里」。差别往往不在读者能力，而在文档的颗粒度——它决定了读者能自己走多远。 我