数据库设计20条军规：血泪教训换来的实战指南

优秀的数据库设计不是炫技，而是用最低的成本规避最痛的坑。在经历过数百次深夜故障复盘后，我总结了这些真正经得起生产环境考验的铁律：

一、基础生存法则

1. 第三范式是起点不是终点
   订单表里的收货地址必须拆成独立地址表？先看业务场景：日均10万订单的电商系统，拆分会带来3表关联查询，不拆可能存储冗余。实战解法：高频查询字段适当冗余，低频字段严格范式化。

2. 命名规范要强制执行
   user_order_2023 比 tbl_usr_odr23 更友好，禁用拼音缩写（比如yhxx表示用户信息）。字段名禁用保留字，时间字段统一用_at后缀（created_at）。

3. 主键设计三原则

• 自增ID：单机系统最佳选择
• UUID：分布式系统必备，但索引性能下降30%
• 联合主键：最多3个字段，超过就要考虑代理键

二、实战性能军规

4. 索引不是万灵药
   给user表的status字段加索引？当这个字段只有0/1两种值时，索引完全失效。正确做法：联合索引前置高频区分字段，例如index(status, created_at)

5. 严禁在数据库里做计算
   错误示例：SELECT SUM(price*quantity) FROM orders
   正确做法：新增total_amount字段存储计算结果，用触发器维护

6. 冷热数据分离
   用户操作日志3个月后查询概率下降80%，按月分表logs_202301，历史数据转存ClickHouse

三、避坑关键细节

7. 金额字段不用FLOAT
   DECIMAL(19,4)存储金额，避免119.34变成119.33999999999999

8. **禁止SELECT ***
   查询10个字段但只用3个？这会让索引覆盖失效，内存消耗增加3倍

9. 预留30%字段扩展空间
   用户表增加wechat_id字段时，如果原有字段长度占满页空间的85%，会导致页分裂

四、高阶优化策略

10. 读写分离不是银弹
    主从延迟导致用户刚下单后查询不到订单？关键业务操作强制走主库

11. 拆字段比拆表更有效
    用户画像表有200个字段，拆分成user_base（高频）、user_tags（低频）两个表，QPS提升4倍

12. 枚举值必须建字典表
    订单状态直接存ENUM('pending','paid')？当需要增加’canceled’状态时，ALTER TABLE会导致锁表

五、终极保命技巧

13. 数据归档方案先行
    上线前就要设计好orders表归档到orders_archive的方案，否则3年后500G大表无法ALTER

14. 版本字段不能少
    乐观锁必备version字段，避免并发扣减库存出现超卖

15. 敏感字段三重保护
    密码用bcrypt哈希，手机号AES加密，连表查询权限独立控制

---

最后三条血泪忠告：

• 永远保留数据删除的后悔药（软删除+归档机制）
• 每个字段都要有注释，三年后你会感谢自己
• 数据库变更必须走评审，DBA的眼睛能救命

好的设计是改出来的，但有些错误一旦发生就是灾难。这些规则不是束缚，而是让你在关键时刻拥有选择的权利。记住：数据库没有彩排，每天都是正式演出。