字段注释决定问数的上限

公开实现文章里有一条很不时髦的经验：忽略最基础的工作——把表名、字段名、业务含义、数据格式写清楚。有人补了三十个核心字段的语义注释，可用率就从「经常蒙对」变成「多数能核」。我把它当成上限，而不是优化项。

核心字段优先

时间、金额、状态、用户、地区、类目。先这六类。

格式也是含义

金额是元还是分，时间是本地还是 UTC，不写就会在对账时爆。

注释要有主人

没人维护的注释会腐烂。腐烂的注释比没有更危险。

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

核对 pay_amount 的单位是元还是分，再决定要不要 /100。

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

SELECT MIN(pay_amount), MAX(pay_amount), AVG(pay_amount)
FROM orders
WHERE pay_time >= CURRENT_DATE - INTERVAL '7 day'
  AND pay_status = 'paid';

量级会揭穿单位。注释若和量级打架，信量级，回头改注释。

结构是地图，不是附录

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

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

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

读完这一辑可以做什么

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

上限往往不在说法，而在三十个核心字段有没有人维护。