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

三条底线:
全库 snake_case,不用驼峰进 MySQL 同一概念全库一个词:删除就是is_deleted,不要旁支 is_del 索引名能脱离 COMMENT 读懂用途 字符集统一 utf8mb4,引擎 InnoDB,和命名无关但和落地一致。
`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 这种缩写(除非全库极早期已统一且不再扩散) `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,避免「神奇数字」 `goods_status` / `order_status` / `pay_status` / `refund_status``idcard_status` / `distributor_status` / `apply_status`少用单独一个 status。
多状态并存时(订单上既有履约又有退款又有开票),每个维度一个字段名,例如订单上的 order_statusrefund_statusinvoice_status。
`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 成对出现 两类并存,但各有场景:
| 风格 | 场景 | 示例 |
|---|---|---|
*_at | 通用创建更新、软删 | create_at、update_at、deleted_at |
*_time | 流程节点、登录、支付完成 | login_time、payment_time、pay_time |
同一张表内保持可读即可;禁止同一含义两列(既有 create_at 又有 add_time 表示同一件事)。
订单这类流程表会有多个 *_time,属于业务节点,不算违规。
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| 前缀 | 用途 |
|---|---|
| (主键) | PRIMARY KEY (id) |
udx_ | 唯一索引 |
idx_ | 普通 / 联合索引 |
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`)KEY a (store_id)KEY index_1 (...) 联合索引名叫 idx_status(看不出还有 user_id) 能进枚举的字段,注释至少包含取值:
COMMENT '支付状态 0未支付 1已支付 2已关闭'COMMENT '实名认证状态(0默认1审核中2未通过3已认证)'COMMENT '支付渠道 alipay wechat'名字负责检索,注释负责对齐前端字典 / 后端 Enum。
DSMall 多端(用户、店铺、骑手、技师)共用同一套库时,这比再写一份「字段说明 Excel」更抗丢失。
| 你在改什么 | 表大概在 | 字段注意 |
|---|---|---|
| 上架/库存/促销标 | 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 |
都过了,字段和索引的命名就可以合并进主干。
表前缀解决「去哪个房间」,字段和索引解决「房间里东西怎么摆」。
后者才是每天 CRUD 的手感来源——DSMall 更愿意在手册里写细这一层。