数据库表怎么设计 ​

许多人一提到数据库表设计，往往先讲三大范式。范式固然是数据库设计的理论基础，但在今天微服务普及、高并发成为常态的架构环境下，仅依赖范式已不足以应对实际挑战。

真正优秀的数据库设计，目标从来不只是节省存储空间，而是追求系统的高性能、高扩展性与高可用性。

基于这样的理念，我总结了日常设计中的一些实用技巧。

1、反范式 ​

在核心业务设计，尤其是高并发读场景下，我会采用反范式设计思路，以空间换取时间。

以电商订单表为例，通常会在订单表中直接冗余商品关键信息，而不是在查询高峰期频繁通过联表查询获取。在微服务架构下，如果商品服务与订单服务分离，这种做法还能有效减少跨服务网络调用，降低I/O开销。

其优势主要体现在两个方面：

• 避免查询瓶颈：将高频访问的数据提前冗余，避免在流量洪峰时出现数据库连接竞争或查询延迟；
• 锁定数据快照：订单一旦生成，其关联的商品信息（如价格、标题等）即被固化，确保后续商品信息变更不会影响订单历史数据的准确性。

2、冷热分离 ​

在亿级数据量的系统设计中，根据数据的访问频率进行冷热分离，是一项基础且关键的策略。

例如在日志表中，常用的功能名称、操作人、时间等字段属于热数据，会被频繁查询；而请求详情、响应内容等字段则属于冷数据，访问较少。这时，就可以将日志表拆分为：

• log_info（日志核心表）：存放热数据，保持表结构精简，提升查询性能；
• log_details（日志详情表）：存放冷数据，按需访问，降低主表负担。

这样设计的好处是，热数据表体积小、查询快。

如果是用户信息这类高频访问信息，甚至可以结合 Redis 等缓存，将高频访问的用户信息常驻内存，实现更高效的三级缓存体系。

3、预留扩展字段设计 ​

根据未来业务的不确定性，可以在核心且频繁迭代的数据表中，预留一个 JSON 扩展字段。

这个字段通常被命名为类似 attr、extra、extension 或 custom_data，用于承载短期内难以完全结构化或频繁变动的业务属性。 通过这种方式，可以在不影响主表结构、不频繁执行 DDL 操作的情况下，灵活应对需求的快速变化，从而实现“弹性表结构”的设计目标，兼顾系统稳定性和迭代效率。

4、其他 ​

分库分表、索引设计等，都是可以去补充的方案。