先让语句跑得对，再谈跑得快

公开落地清单把性能护栏写成限扫描、限行、限时，必要时走汇总表。那是在语句已经对的前提下。个人练习先对账，再看执行计划。用索引和汇总表去救一条口径错误的语句，会把错误生产化。

先小窗

一天对了再一月。

再换汇总表

日报表和明细对得上，才允许日常问日报。

最后才 EXPLAIN

计划能告诉你扫了多少，不能告诉你口径对不对。

一次完整的问法可以先写成下面这样：

同一口径在明细和日汇总上对一天的账。

落到语句上，草稿常常是：

SELECT
  (SELECT SUM(pay_amount) FROM orders WHERE pay_time >= DATE '2026-03-01' AND pay_time < DATE '2026-03-02' AND pay_status='paid') AS detail_gmv,
  (SELECT gmv FROM dws_order_day WHERE dt = DATE '2026-03-01') AS dws_gmv;

两个数一致，再谈快。不一致，快没有资格上台。

语句是收据，默认只读

第一纪律是 SELECT。草稿里出现更新、删除、结构变更，整张收据作废。第二纪律是时间窗。大表没有时间条件，不跑。第三纪律是粒度。GROUP BY 的键必须和问题里的维度一一对应。

一对多关联会把头上的金额按明细复制，看起来像增长，其实是扇形。COUNT 和 COUNT DISTINCT 不是同一指标。NULL 不是 0。日期函数没有世界语，能写绝对区间就写绝对区间。

复杂逻辑用公共表表达式拆开。拆开是为了给人看中间结果。先对再快。用索引去救一条口径错误的语句，会把错误生产化。

读完这一辑可以做什么

把你最近一条问数语句拆成三段 WITH：过滤、聚合、排名。每一段单独跑。有一段解释不清，就回到提问，不要在语句里继续加花样。

先对一天，再谈一个月和执行计划。