3. Schema命名规范：表名、字段名、索引名的命名规则与最佳实践
命名这件事，说实话，在很多人眼里就是个「起名字」的活儿。但我在数据治理这行干了十几年，见过太多因为命名混乱导致的灾难——数据对不上、ETL跑崩、新人接手想骂娘。一个好的命名规范，能让你的数据资产价值翻倍；一个烂的命名规范，能让整个数仓变成垃圾场。
今天我就把这些年踩过的坑、总结的经验，一次性说清楚。
3.1 表名命名规则：从业务域到技术属性的完整映射
表名是数据资产的身份证。我个人习惯，表名必须包含三个要素：业务域 + 数据主题 + 技术属性。缺一个，后面都会出问题。
核心公式：
[业务域缩写]_[数据主题]_[技术后缀]
举个例子，我在某电商平台做治理时，订单域的表名是这样设计的：
| 业务域 | 数据主题 | 技术后缀 | 完整表名 | 说明 |
|---|---|---|---|---|
| ord | order_info | _df | ord_order_info_df | 订单明细事实表 |
| ord | order_status | _ds | ord_order_status_ds | 订单状态维度表 |
| usr | user_profile | _ds | usr_user_profile_ds | 用户画像维度表 |
| fin | payment_flow | _df | fin_payment_flow_df | 支付流水事实表 |
技术后缀这块，我建议统一用以下约定：
- _df：事实表（Data Fact）
- _ds：维度表（Data Dimension）
- _stg：临时/贴源层（Staging）
- _mid：中间表（Intermediate）
- _agg：汇总表（Aggregation）
- _log：日志表（Log）
避坑指南：我曾经见过一个项目，表名里既没有业务域也没有技术后缀，全是「t1」「t2」「tmp_xxx」这种名字。半年后，连写这些表的人都不知道它们干嘛用的。最后不得不花两个月做数据血缘回溯，才把表用途搞清楚。所以，表名里一定要带上业务域和技术属性，这是底线。
3.2 字段名命名规则：清晰、一致、可自解释
字段名是数据的最小单元，命名质量直接影响数据理解成本。我总结了一个「三要三不要」原则：
3.2.1 三要原则
- 要全小写+下划线：
user_id而不是userId或USER_ID - 要语义完整：
order_create_time而不是create_time（谁知道是哪个对象的创建时间？） - 要类型暗示：布尔字段用
is_、has_开头，时间字段用_time、_date结尾
3.2.2 三不要原则
- 不要用保留字：比如
order、group、select这些，SQL里会出大问题 - 不要用缩写：除非是团队公认的缩写（如
id、cnt），否则一律写全称 - 不要用无意义前缀：比如
f_、col_，纯属浪费字符
我的个人习惯：字段名长度控制在 20 个字符以内。太长了，写SQL时手累；太短了，语义表达不清。如果实在需要长字段名，优先考虑用业务缩写，比如 cust_risk_score 代替 customer_risk_score。
来看一个实际对比：
| ❌ 反面案例 | ✅ 正面案例 | 问题说明 |
|---|---|---|
| create_time | order_create_time | 缺少对象归属，容易混淆 |
| flag | is_active | flag含义模糊，不知道是啥标志 |
| dt | order_date | dt太通用，无法区分日期还是时间 |
| user_name_first | user_first_name | 命名顺序混乱，不符合阅读习惯 |
3.3 索引名命名规则：一眼看懂索引用途
索引命名，很多人觉得无所谓。但我在一次数据库性能优化中，因为索引名全是 idx_1、idx_2 这种，排查问题时差点崩溃。后来我定了一个规则：索引名必须包含表名、字段名和索引类型。
标准格式：
[索引类型]_[表名]_[字段名1]_[字段名2]其中索引类型缩写：
- idx：普通索引（Index）
- uniq：唯一索引（Unique）
- pk：主键索引（Primary Key）
- ft：全文索引（Full Text）
- com：复合索引（Composite）
举个例子：
-- 普通索引
idx_ord_order_info_order_status
-- 唯一索引
uniq_usr_user_profile_email
-- 复合索引
com_ord_order_info_user_id_order_create_time
-- 主键
pk_ord_order_info_order_id避坑指南：我曾经接手过一个系统，索引名全是 index_1 到 index_50。有一次要删一个冗余索引，DBA 对着列表看了半天，根本不知道哪个对应哪个字段。最后只能一个个查 SHOW INDEX 来确认。所以，索引名一定要自描述，别偷懒。
3.4 命名规范落地：从制度到工具
光有规范没用，得落地。我建议分三步走：
- 制定规范文档：把表名、字段名、索引名的规则写清楚，附上正反案例，全员评审通过
- 嵌入开发流程：在代码审查（Code Review）中增加命名规范检查项，不通过不能合并
- 自动化检查：用工具（如 SQLFluff、自研脚本）自动扫描DDL，不符合规范的直接报错
我的经验：自动化检查是最有效的。人眼审查总有漏网之鱼，但脚本不会。我在一个项目中写了200行Python脚本，每天凌晨扫描所有新建表，把不符合规范的DDL发到群里@责任人。一个月后，命名规范遵守率从60%提升到了95%。
3.5 命名规范全景图
下面这张图，是我总结的命名规范知识体系。你可以把它当成团队培训的入门材料：
嗯，这张图基本把命名规范的核心内容都涵盖了。你想想看，如果团队里每个人都能按这个规范来命名，数据资产的管理成本至少降低一半。
最后说一句：命名规范不是束缚，而是解放。好的规范让你不用每次写SQL时都去猜「这个字段到底是什么意思」。我见过太多团队在命名上「自由发挥」，结果就是数据沼泽。所以，从今天开始，给你的Schema定个规矩吧。