DSMall 字段和索引如何起名:比表前缀更影响日常开发

作者:袖梨 2026-08-10

表名有 sys_ / tbl_ / trade_ 做导航之后,日常写代码接触最多的其实是字段和索引。

DSMall 字段和索引怎么起名:比表前缀更影响日常开发

1. 总原则:名字是给「联表和搜索」用的

三条底线:

全库 snake_case,不用驼峰进 MySQL 同一概念全库一个词:删除就是 is_deleted,不要旁支 is_del 索引名能脱离 COMMENT 读懂用途

字符集统一 utf8mb4,引擎 InnoDB,和命名无关但和落地一致。

2. 字段类型 × 命名对照

2.1 主键与外键

`id` int NOT NULL AUTO_INCREMENT,`user_id` int NOT NULL COMMENT '买家/会员ID',`store_id` int NOT NULL COMMENT '店铺ID',`goods_id` int NOT NULL,`order_id` int NOT NULL
主键固定 id 外键固定 被引用表语义_id,不写 uidsid 这种缩写(除非全库极早期已统一且不再扩散)

2.2 开关与布尔

`is_enabled` tinyint DEFAULT 1 COMMENT '0禁用 1启用',`is_deleted` tinyint DEFAULT 0 COMMENT '0未删除 1已删除',`is_distributor` tinyint DEFAULT 0 COMMENT '是否分销商',`mobile_bind` tinyint DEFAULT 0 COMMENT '是否绑定手机'

习惯:

是/否 → is_* 或语义清晰的 *_bind 取值注释写清 0/1,避免「神奇数字」

2.3 业务状态

`goods_status` / `order_status` / `pay_status` / `refund_status``idcard_status` / `distributor_status` / `apply_status`

少用单独一个 status

多状态并存时(订单上既有履约又有退款又有开票),每个维度一个字段名,例如订单上的 order_statusrefund_statusinvoice_status

2.4 金额与计量

`balance` decimal(20,4) COMMENT '预存款可用',`balance_in` / `balance_out` COMMENT '累计收入/支出',`pay_amount` / `refund_amount` decimal(20,4),`points` / `points_in` / `points_out` int
钱:decimal,名字带业务角色(pay / refund / shipping…) 积分、次数:int,累计进出可用 *_in / *_out 成对出现

2.5 时间

两类并存,但各有场景:

风格场景示例
*_at通用创建更新、软删create_atupdate_atdeleted_at
*_time流程节点、登录、支付完成login_timepayment_timepay_time

同一张表内保持可读即可;禁止同一含义两列(既有 create_at 又有 add_time 表示同一件事)。

订单这类流程表会有多个 *_time,属于业务节点,不算违规。

3. 会员表示例:一套字段里看出习惯

user 表是字典式样板——命名密度高,适合新人对照:

`username` varchar(32),`nickname` varchar(32),`mobile` varchar(11),`mobile_bind` tinyint,`inviter_id` int COMMENT '邀请人',`balance` decimal(20,4),`balance_in` decimal(20,4),`balance_out` decimal(20,4),`points` int,`points_in` int,`points_out` int,`idcard_status` tinyint COMMENT '0默认 1审核中 2未通过 3已认证',`is_enabled` tinyint,`is_distributor` tinyint,`distributor_status` tinyint,`distributor_level_id` int

可以看出:

认证、分销都是「前缀包一层」:idcard_*distributor_* 资产有余额、有积分,进出成对 开关与状态分离:is_distributor vs distributor_status

4. 索引命名手册

4.1 前缀

前缀用途
(主键)PRIMARY KEY (id)
udx_唯一索引
idx_普通 / 联合索引

4.2 怎么拼名字

UNIQUE KEY `udx_username` (`username`),UNIQUE KEY `udx_order_sn` (`order_sn`),KEY `idx_user_id` (`user_id`),KEY `idx_store_id` (`store_id`),KEY `idx_pay_status` (`pay_status`),KEY `idx_create_at` (`create_at`),KEY `idx_user_id_status` (`user_id`, `status`)-- 联合:字段顺序写入名称

支付流水上常见:

UNIQUE KEY `udx_out_trade_no` (`out_trade_no`),UNIQUE KEY `udx_trade_no` (`trade_no`),KEY `idx_source_type` (`source_type`),KEY `idx_source_id` (`source_id`),KEY `idx_pay_channel` (`pay_channel`)

4.3 不建议

KEY a (store_id)KEY index_1 (...) 联合索引名叫 idx_status(看不出还有 user_id

5. COMMENT 最低标准

能进枚举的字段,注释至少包含取值:

COMMENT '支付状态 0未支付 1已支付 2已关闭'COMMENT '实名认证状态(0默认1审核中2未通过3已认证)'COMMENT '支付渠道 alipay wechat'

名字负责检索,注释负责对齐前端字典 / 后端 Enum。

DSMall 多端(用户、店铺、骑手、技师)共用同一套库时,这比再写一份「字段说明 Excel」更抗丢失。

6. 和表前缀怎么配合(只留一张速查)

你在改什么表大概在字段注意
上架/库存/促销标tbl_goodsis_*_goodsgoods_statusplatform
下单履约售后tbl_order*order_statusrefund_**_time
渠道支付退款trade_*out_trade_nopay_statussource_*
会员资产认证userbalance_*points_*idcard_*
系统配置内容sys_*config_key / 业务自己的 code

7. Review 时三句口头禅

这个字段换个表,名字还会产生歧义吗? 索引名能否直接告诉我查询条件? COMMENT 能否让前端不用再来问枚举?

都过了,字段和索引的命名就可以合并进主干。

表前缀解决「去哪个房间」,字段和索引解决「房间里东西怎么摆」。

后者才是每天 CRUD 的手感来源——DSMall 更愿意在手册里写细这一层。

相关文章

精彩推荐