关联键说不清，就不要硬 JOIN

JOIN 是问数里最像「我会写 SQL」的动作，也是最容易把数乘开的动作。公开文章把描述表当成验证主键外键的步骤。个人练习更土：先分别 COUNT，再 COUNT 连接后的行数，行数暴涨就停。

一对多要承认

订单连明细，行数会变多。金额若在订单头上，连完再 SUM 会炸。

键的类型要一致

一边是文本一边是整数，看起来连上了，其实丢掉了沉默的行。

没有文档就抽样对键

两边各取若干 id，看能对上多少。对不上，不要用「大概是这个」。

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

验证 orders.order_id 与 order_items.order_id 能否对齐。

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

SELECT
  (SELECT COUNT(*) FROM orders) AS orders_cnt,
  (SELECT COUNT(*) FROM order_items) AS items_cnt,
  (SELECT COUNT(*) FROM orders o JOIN order_items i ON i.order_id = o.order_id) AS joined_cnt;

三个计数摆在一起，关联是不是一对多，一目了然。一目了然之后，才允许写业务汇总。

结构是地图，不是附录

公开实现文章把列出表、描述字段、抽样行、再执行写成四件工具。工具顺序不能倒。执行放第一位，等于闭眼过马路。

结构链接的失败，十之八九不是语法。是找错表、找错列、找错枚举值。注释、别名、示例值，是地图上的注记。注记质量决定问数上限。有人只补三十个核心字段的含义，可用程度就明显上升。这是最不时髦、也最管用的工作。

语义层是把指标、维度、关联路径写成中间层。个人没有引擎时，用字典和卡片冒充。没有这一层，每次提问都在重新发明销售额。宽表好问、星型好管，选边可以，口径必须唯一。

读完这一辑可以做什么

给十个核心字段写注释：时间、金额、状态、用户、地区、类目，外加四个你会用到的。注释里写计算、单位、示例值。写完再去问数，少猜一轮。

连接前后的三个计数，比直觉更早发现一对多。