标签频道
SQL
该标签下的文章、提问与讨论帖。
背景 我们使用 H2 数据库管理一个日志审计系统，核心表 "t_audit_log" 规模达到 4800 万行、单表 62GB、InnoDB、MySQL 8.0.32，部署在 16C64G、NVMe 本地盘的服务器上。业务方反馈该表的某高频
«结论先行：指标被回写不是 bug，是迟到数据、退款冲减、维度表变更的必然结果——但「没人知道哪些指标被改过、改了多少、什么时候才稳定」是治理缺失。本文给一套可复现的三件套：分区级改写检测快照、变更分级归因、指标级新鲜度/冻结 SLA，把「
环比 +480% 为什么可能是假增长：基期趋近 0 时百分比爆炸的四种形态与一套可复现的口径 «结论先行：环比 / 同比的百分比变化 "(cur - base) / base" 在 "base → 0" 时不是"变大"，而是失去意义——它同
改「活跃用户」定义后 3 个派生指标悄悄跳 7%：指标级血缘的原子-派生依赖图与口径传递检测 «结论先行：改一张表、改一个字段会炸掉下游看板，这件事社区已经写过很多了（见 postId 650「改一个字段炸掉 14 个看板」）。但还有一类更
月末日 DAU 凭空多出 18%：UTC 切日 vs 本地时区切日的错位复盘与双时间戳改造方案 «结论先行：同一份用户事件数据，用 "DATE(event_time)"（UTC）切日和用"用户所在时区的当地日"切日，在月末日、跨时区业务、夏
同一笔订单，两个时间字段：下单时间 vs 支付时间如何悄悄改写月度 GMV «结论先行：「GMV 对不上」里有一大类，根因既不是时区、也不是 JOIN 放大，而是「这笔订单到底算哪一天」——而「哪一天」取决于你用的是 "created_at
LEFT JOIN + SUM(IF()) 的 NULL 静默空档：一次看板缺 38% 日期数据的复盘与 SQL 修复 «结论先行："LEFT JOIN" 之后直接 "SUM(IF(...))"，在"右表无行"的日期上会产生 NULL，而不
«站在「指标体系搭建」视角，对比三种异常判定方案的误报率、维护成本与适用场景，给一套可直接跑的 SQL 与阈值参数。» 一、现象与背景：告警疲劳比漏报更致命 接手一个 B 端数据平台，监控 42 个核心业务指标（DAU、付费转化率、订单量、
一、现象与背景 某电商增长看板，整体支付转化率从 4.28% 掉到 4.04%（-0.24pp，相对降幅约 5.6%），日均曝光 UV 约 120 万，我用两个时点各取 7 天窗口做对比（基期 09-01~09-07，报告期 09-08~0
人均 GMV 凭空多出 2.5 倍：一对多 JOIN 放大（fan-out）让 SUM/COUNT 静默虚增的根因与三层解法 «结论先行：大多数「指标对不上」不是数据错了，而是聚合粒度错了。当你把「一」侧的指标（如订单金额）和「多」侧的行（
一、现象与背景 过去一年我在三家团队都撞过同一堵墙：产品说「7 日留存只有 18%」，增长说「我们 7 日留存稳定在 27%」，数据看板上一周前是 21%。三个数都来自同一张用户表、同一个埋点，差异不是噪声，而是口径。 规模上这件事很贵：一
文
标题
摘要