数据库字段命名规范速查表

这是一份基于业界主流实践（如阿里巴巴 Java 开发手册、大厂数据库规范）总结的数据库字段命名规范速查表。你可以直接将其作为团队的开发规范落地。

一、 核心命名原则（3个铁律）

1. 全小写+下划线分隔 ：所有表名、字段名必须使用小写字母，单词间用下划线 _ 连接（如 user_name），严禁 使用驼峰命名（userName）或大写。
2. 见名知意，拒绝拼音 ：必须使用准确的英文单词（如 create_time），严禁使用拼音（如 chuangjian_shijian）或无意义的缩写（如 crt_tm）。
3. 绝对避开保留字 ：严禁使用数据库保留字（如 key, order, group, desc, value, status 等）。如果必须表达该含义，请加业务前缀（如 config_key, order_no）。

---

二、 字段命名分类速查表

1. 通用元数据字段（所有表必备）

这类字段描述的是"记录本身的属性"，通常不加业务前缀。

字段名	数据类型	说明	备注
id	BIGINT	主键	推荐雪花算法或自增，严禁使用 UUID 作为主键（索引性能差）
created_at	DATETIME	创建时间	推荐数据库自动填充，避免应用层时区问题
updated_at	DATETIME	更新时间	必须设置 ON UPDATE CURRENT_TIMESTAMP
is_deleted	TINYINT	逻辑删除标识	0-未删除，1-已删除（配合 MyBatis-Plus 等框架使用）
version	INT/BIGINT	乐观锁版本号	每次更新自增，防止并发覆盖

2. 业务专属字段（需加业务前缀）

当字段名过于通用，脱离表名后会产生歧义时，必须加表名或业务前缀。

错误命名 ❌	正确命名 ✅	适用场景	原因说明
name	user_name	用户表	避免与其他表的 name 混淆，JOIN 查询时更清晰
status	order_status	订单表	status 太泛，加前缀明确是订单状态还是支付状态
type	pay_type	支付记录表	明确是支付类型，而非用户类型或商品类型
key	config_key	配置表	key 是保留字，且语义不明
value	config_value	配置表	value 是保留字，且语义不明

3. 常见业务词汇标准翻译（防拼写错误）

团队中应统一以下常用词的英文表达，避免同义词混用：

业务含义	推荐字段名	严禁使用的词
手机号	mobile / phone	tel, shouji
邮箱	email	mail, youxiang
密码	password	pwd, pass
头像	avatar	head_img, pic
昵称	nickname	nick, alias
余额	balance	money, cash
金额/价格	amount / price	num (易与数量混淆)
数量	quantity / count	num
状态	status	state (保持团队统一)
备注	remark	note, memo

---

三、 字段命名后缀规范（数据类型暗示）

通过字段名的后缀，可以直接猜出它的数据类型，极大提升代码可读性：

后缀	暗示类型	示例
_id	BIGINT / INT	user_id, order_id
_no / _code	VARCHAR	order_no, verify_code
_name	VARCHAR	user_name, category_name
_time	DATETIME	pay_time, login_time
_date	DATE	birth_date
_amount / _price	DECIMAL(10,2)	pay_amount, item_price
_flag / is_	TINYINT(1)	is_vip, login_flag

---

四、 表命名规范（补充）

1. 表名使用单数 ：使用 user, order，严禁 使用 users, orders。
2. 前缀分类法 ：如果系统较大，建议加业务线前缀。例如：sys_config（系统配置）、biz_order（业务订单）、pay_record（支付记录）。
3. 关联表命名 ：多对多关联表使用 a_b_rel 格式，如 user_role_rel（用户角色关联表）。