sql 表结构设计是围绕业务逻辑、数据一致性、查询效率和长期可维护性的系统性决策，核心是用最小冗余表达完整语义，让数据自己“说话”。
SQL 表结构设计不是单纯写 CREATE TABLE 语句，而是围绕业务逻辑、数据一致性、查询效率和长期可维护性做的系统性决策。核心原则是：用最小冗余表达完整语义，让数据自己“说话”，而不是靠应用层硬编码规则。
字段设计：类型精准 + 含义明确
避免万能 VARCHAR(255) 或盲目用 TEXT；优先选有语义约束的类型：
- 状态类字段（如订单状态）用 TINYINT 或 ENUM（MySQL）+ 注释说明取值含义，比 VARCHAR 更省空间且防非法值
- 金额统一用 DECIMAL(12,2)，不用 FLOAT/DOUBLE——浮点数无法精确表示货币
- 时间字段按需选：创建时间用 DATETIME（含时区无关性），日志类时间可用 TIMESTAMP（自动更新），仅日期需求用 DATE
- 主键优先用自增 BIGINT（而非 INT，防未来 ID 溢出），高并发场景可考虑雪花 ID 但需应用层生成或数据库函数支持
关系建模：外键要设，但别滥用级联
外键是保障参照完整性的基础设施，不是性能包袱：
- 一对一、一对多必须显式定义外键，并命名规范（如 fk_order_user_id）
- 禁止用字符串拼接模拟关联（如“user_ids:1,3,5”），这等于放弃数据库约束能力
- CASCADE DELETE/UPDATE 谨慎使用——多数业务中软删除（is_deleted=1）比物理级联更安全可控
- 多对多必须拆成独立关联表，带复合主键（如 user_id + role_id）并分别建索引
索引策略：查什么，建什么，定期看执行计划
索引不是越多越好，而是为高频查询路径服务：
- WHERE 条件中的字段、JOIN ON 字段、ORDER BY 字段是索引主要候选
- 联合索引注意最左前缀原则：INDEX(a,b,c) 能加速 WHERE a=1 AND b=2，但对 WHERE b= 2 无效
- 避免在区分度低的字段建索引（如 gender、is_deleted），除非配合其他高区分字段组成联合索引
- 定期用 EXPLAIN 分析慢查询，关注 type（是否走索引）、rows（扫描行数）、Extra（是否 Using filesort/Using temporary）
扩展性与演进：预留空间，拒绝“一步到位”
表结构会随业务生长，设计时要留出安全裕度：
- 字段注释必写，用 COMMENT 关键字，说明业务含义、取值范围、变更历史
- 不提前预设“未来可能用到”的字段（如 ext_json、remark），需要时再 ALTER ADD，保持表语义清晰
- 大文本、附件路径、富媒体地址单独建扩展表，主表只存关键标识，避免主表臃肿影响高频查询
- 单表字段数建议控制在 30 个以内，超 50 列需警惕设计抽象是否合理
表结构是数据世界的地基。它不炫技，但每处设计都在默默影响着系统的稳定性、扩展成本和排查难度。一次审慎的建表，胜过十次补丁式优化。
