相关表只要几张：把结构检索当成选地图

公开的结构链接讨论说得很白：失败的十之八九不是语法，是找错表或找错列。检索要高召回，再收窄到几张真正相关的表。个人练习时，我用问题里的名词去对注释和同义词，对不上就停。

先宽后窄

先把可能相关的表都找出来，再删掉无关的。删太早，会漏掉关联表。

值和名字一起找

问题里的「已支付」可能不是列名，是列值。既要检索字段，也要检索枚举。

反向也可以

有人先写一条粗糙语句，再从语句里抽出用到的表，作为精简地图。两种方向可以对照。

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

「上个月销售额最高的产品」可能相关的表：orders、order_items、products。先这三张。

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

SELECT p.product_name, SUM(i.pay_amount) AS gmv
FROM order_items i
JOIN products p ON p.product_id = i.product_id
JOIN orders o ON o.order_id = i.order_id
WHERE o.pay_time >= DATE '2026-03-01'
  AND o.pay_time < DATE '2026-04-01'
  AND o.pay_status = 'paid'
GROUP BY p.product_name
ORDER BY gmv DESC
LIMIT 1;

三张表已经够吵。若把用户日志也拉进来，销售额会开始包含点击。选地图是纪律。

结构是地图，不是附录

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

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

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

读完这一辑可以做什么

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

相关表只要几张。整库塞进来，结构链接会变成吵闹。