表名有 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_status + refund_status + invoice_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_distributorvsdistributor_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 更愿意在手册里写细这一层。
