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

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

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，不写 uid、sid 这种缩写（除非全库极早期已统一且不再扩散）

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_at、update_at、deleted_at
*_time	流程节点、登录、支付完成	login_time、payment_time、pay_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_goods	is_*_goods、goods_status、platform
下单履约售后	tbl_order*	order_status、refund_*、*_time
渠道支付退款	trade_*	out_trade_no、pay_status、source_*
会员资产认证	user	balance_*、points_*、idcard_*
系统配置内容	sys_*	config_key / 业务自己的 code

7. Review 时三句口头禅

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

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

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

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