数据库字段命名规范及核心原因

结合行业通用标准、SQL 语言特性及企业级开发实践，整理数据库字段命名的核心规范、背后原因及示例，同时适配 SpringBoot + MyBatis-Plus 等主流技术栈，兼顾规范性、兼容性与可维护性。

一、核心命名规范（行业通用标准）

1. 基础格式规范

规范项	要求	示例
分隔符	统一使用下划线（蛇形命名法） 分隔单词，禁止使用驼峰、空格、特殊符号	user_name、order_pay_time
大小写	全小写字母，禁止大小写混用、全大写	正确：created_at；错误：CreatedAt、CREATED_AT
语义性	必须见名知意，使用标准英文单词，禁止拼音、无意义缩写（通用行业缩写除外）	正确：user_phone；错误：yh_sj（用户手机拼音）、usr_ph（非通用缩写）
简洁性	长度控制在 30 字符内，避免冗余描述，核心信息前置	正确：order_status；错误：order_current_status_info
禁止保留字	避免使用 SQL 关键字（如 order、user、status 可加前缀，或用同义替换）	正确：order_info、user_account；错误：直接用 order 作为字段名

2. 时态与功能规范

（1）操作类字段（创建/更新/删除）

• 表示“已完成的操作”，统一使用过去分词（符合英语语法，且与行业惯例一致）
• 时间字段后缀统一用 _at，操作人字段后缀统一用 _by/_id

  字段类型	规范命名	示例
  创建时间	xxx_at	created_at、order_created_at
  创建人	xxx_by/xxx_user_id	created_by、created_user_id
  更新时间	xxx_at	updated_at
  更新人	xxx_by/xxx_user_id	updated_by
  删除时间（软删除）	xxx_at	deleted_at
  删除人（软删除）	xxx_by/xxx_user_id	deleted_by

（2）状态/布尔类字段

• 布尔值（是/否）：统一前缀 is_，值为 0/1 或 true/false
• 枚举状态：后缀 _status/_type，明确字段含义

  字段类型	规范命名	示例
  布尔状态	is_xxx	is_deleted（是否删除）、is_enable（是否启用）
  业务状态	xxx_status	order_status（订单状态）、user_status（用户状态）
  类型区分	xxx_type	pay_type（支付类型）、user_type（用户类型）

（3）主键与外键规范

• 主键：单表主键统一命名为 id（自增/UUID 均可），无需加表名前缀
• 外键：关联表主键 + _id，严格与关联表主键命名一致

  字段类型	规范命名	示例
  单表主键	id	用户表主键 id、订单表主键 id
  关联外键	关联表名_id	订单表关联用户表：user_id；订单详情表关联订单表：order_id

3. 通用审计字段规范（所有业务表标配）

成熟系统的业务表必须包含以下审计字段，命名统一，无特殊情况不修改：

id              BIGINT      NOT NULL AUTO_INCREMENT COMMENT '主键ID',
-- 核心业务字段 ...
created_by      BIGINT      COMMENT '创建人ID',
created_at      DATETIME    NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
updated_by      BIGINT      COMMENT '更新人ID',
updated_at      DATETIME    NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
is_deleted      TINYINT     NOT NULL DEFAULT 0 COMMENT '是否删除：0-未删除，1-已删除',
PRIMARY KEY (`id`)

4. 特殊场景补充规范

1. 通用缩写：仅允许使用行业通用缩写（如 id、no、code、amt、qty），禁止自定义缩写
   示例：order_no（订单号）、pay_amt（支付金额）、stock_qty（库存数量）
2. 多表关联字段：跨表关联的相同含义字段，命名必须完全一致
   示例：用户表 id，所有关联表统一用 user_id，禁止出现 uid、userid 等变体
3. 时间字段：精确到时分秒用 DATETIME，仅日期用 date，时间字段后缀统一 _at
   示例：pay_time 改为 pay_at，create_time 改为 created_at

二、规范背后的核心原因

1. 适配 SQL 语言的底层特性（最关键原因）

SQL 标准规定标识符（表名、字段名）默认不区分大小写，不同数据库实现存在差异：

• MySQL Windows 不区分大小写，Linux 默认区分；PostgreSQL/Oracle 会将未加引号的标识符转为小写；
• 若使用驼峰命名（如 userName），数据库会默认解析为 username，语义丢失；若保留驼峰，必须用引号/反引号包裹（如 userName），书写繁琐且易报错；
• 下划线命名（user_name）天然分隔单词，无需额外符号，完美适配 SQL 大小写特性，是最实用的选择。

2. 提升跨系统/工具的兼容性

• 主流数据库（MySQL、PostgreSQL、Oracle、SQL Server）、数据工具（Navicat、DBeaver）、数据同步工具（Canal、DataX）均原生支持下划线命名，无兼容性问题；
• 跨语言开发（Java、Python、Go、PHP）时，下划线命名是全语言通用风格，无需额外做字段名映射；
• 驼峰命名在老旧工具、跨库迁移场景中易出现解析错误，兼容性远低于下划线。

3. 增强可读性与团队协作效率

• 下划线分隔的单词视觉上更易区分，长字段名（如 user_login_failed_count、order_pay_expire_at）比驼峰更易快速阅读；
• 统一的命名规范让团队成员无需猜测字段含义，降低沟通成本，新人接手项目可快速理解表结构；
• 时态规范（created 而非 create）符合英语语法，更贴合“已完成操作”的语义，避免歧义。

4. 适配主流框架的生态特性

SpringBoot + MyBatis-Plus、JPA、Hibernate 等主流 ORM 框架原生支持下划线与 Java 驼峰的自动映射：

• 数据库 user_name 自动映射为 Java 实体类 userName，无需手动配置 @Column 注解；
• 若数据库用驼峰，需手动配置映射关系，增加开发成本，违背框架的“约定大于配置”理念。

5. 保证可维护性与扩展性

• 统一的命名规则让表结构更规整，后期新增字段、修改字段时，可快速遵循规范，避免字段命名混乱；
• 审计字段、外键、状态字段的统一命名，便于后续做数据统计、权限控制、日志审计等扩展功能；
• 禁止拼音、无意义缩写，避免后期维护时无法理解字段含义，减少技术债务。

三、规范示例 vs 反例对比

字段含义	规范示例	反例（不推荐）	反例问题
用户姓名	user_name	userName、UserName、yhxm	驼峰命名、拼音、大小写混用
创建时间	created_at	create_time、CreateAt、c_time	时态错误、缩写无意义、驼峰
订单状态	order_status	orderState、ddzt、status	驼峰、拼音、使用 SQL 保留字
是否启用	is_enable	enable、isEnable、sfqy	缺少前缀、驼峰、拼音
关联用户ID	user_id	uid、userId、userid	非标准缩写、驼峰、命名不统一
支付完成时间	pay_finish_at	payFinishTime、pay_time	驼峰、后缀不规范、语义模糊

四、最佳实践与注意事项

1. 团队规范统一：项目初期制定命名规范文档，所有成员严格遵守，禁止同一项目中出现多种命名风格（如混用 created_by 和 create_user_id）；
2. 避免过度冗余：无需为字段加无意义前缀/后缀，如 user_info_name（冗余 info），直接用 user_name 即可；
3. 软删除优先：用 is_deleted 实现软删除，而非物理删除，配合 deleted_at/deleted_by 记录删除信息；
4. 字段注释必填：每个字段必须加 COMMENT 注释，明确字段含义、枚举值含义，提升可维护性；
5. 适配业务场景：通用规范为基础，可根据业务做少量调整（如金融系统金额字段统一加 _amt），但核心规则不变。

五、总结

数据库字段命名规范的核心是“适配 SQL 特性、兼顾兼容性、提升可读性”，下划线+全小写+语义化+统一时态是行业通用的最优解。遵循规范不仅能避免技术兼容性问题，还能大幅提升团队协作效率和项目可维护性，是企业级数据库设计的基础要求。对于 SpringBoot + MyBatis-Plus 项目，下划线命名还能享受框架自动映射的便利，是性价比极高的规范实践。