17370845950

表设计应服务于数据生命周期，主键优先选自增ID或UUID，字段类型需精准合义，外键保障一致性但高并发可省略，索引按查询模式创建并遵循最左前缀原则。

表设计不是堆字段，而是为数据生命周期服务。好结构让查询快、维护省、扩展稳。

主键必须用自增整型或UUID，别用业务字段

业务字段（如手机号、订单号）会变、有重复风险、长度不一，不适合作为主键。自增ID（INT UNSIGNED AUTO_INCREMENT）适合内部关联和分页；分布式系统优先选 BIGINT + 雪花ID 或 UUID v4（注意用 BINARY(16) 存，别用 VARCHAR(36)）。

• 避免用“姓名+时间”拼接当主键——查重难、索引大、无法做外键
• 联合主键仅在明确无代理键场景下使用（如多对多关系表），且字段数≤2
• 主键默认加聚簇索引，影响插入顺序和范围查询性能

字段类型要够用、不冗余、合语义

小能不用大，字符不硬转数字，时间不用字符串存。比如用户年龄用 TINYINT UNSIGNED（0–127），别用 INT；状态码用 TINYINT 配注释，别用 VARCHAR(10) 存“active”“inactive”；创建时间必须是 DATETIME 或 TIMESTAMP，带时区需求选前者。

• 手机号统一用 CHAR(11)（国内）或 VARCHAR(16)（国际格式），别用 INT（前导零丢失）
• 金额字段一律用 DECIMAL(12,2)，不用 FLOAT（精度丢失）
• 文本内容超 255 字符优先用 TEXT，但避免在 TEXT 上建索引；高频检索字段仍建议 VARCHAR 并加索引

外键该加就加，但别为加而加

外键保障数据一致性，尤其在核心业务表（如订单→用户、订单→商品）。但高并发写入场景（如日志、消息队列中间表）可去掉外键，靠应用层约束+定期校验。

• 外键字段类型、字符集、排序规则必须与被引用字段完全一致
• 被引用字段必须有索引（通常是主键或唯一索引），否则建外键失败
• 级联操作（ON DELETE CASCADE）谨慎使用，删除动作可能引发隐式大批量更新

索引不是越多越好，按查询模式建有效索引

先看 WHERE、ORDER BY、GROUP BY 用哪些字段，再组合建索引。单列索引优先考虑高频等值查询字段；复合索引遵循“最左前缀原则”，把区分度高、过滤性强的字段放前面。

• 避免对低区分度字段单独建索引（如 gender、is_deleted）
• WHERE a = ? AND b > ? ORDER BY c，适合建联合索引 (a,b,c)，不是 (a,c,b)
• 覆盖索引能减少回表：SELECT id,name FROM user WHERE status=1，可建 (status,name,id) 索引

基本上就这些。规范不是教条，是帮你在数据量涨十倍时少踩坑。