当前位置：首页 > news >正文

接口还是慢，也许是你的表太规范了

news 2026/5/11 20:32:51

当业务逻辑稍微复杂一点，也建立了合适的索引，可能仍然解决不好接口访问数据库时的性能问题。有时，为了遵循数据库第三范式而精心设计的表结构和JOIN查询，正成为新的性能瓶颈。

第一范式（1NF）要求表的每个格子只能存一个值；第二范式（2NF）要求存在多列主键时，属性列必须完全依赖于所有主键列，而不是部分依赖；第三范式（3NF）则要求属性列之间不能存在传递依赖，即如果某列存储了其他列的 ID，就不应再重复存储该 ID 对应的其他属性。通过第三范式设计表结构，可以实现数据无冗余、依赖唯一。

在实际业务中，严格遵循它往往导致许多查询需要通过 JOIN 多张表才能凑齐一条完整信息。要查询满足条件的所有行，可能需要多次扫描全表、连接、排序，耗时耗力。这时，我们就应考虑增加反规范化设计。

1. 冗余列和派生列

冗余列是指违反上述 2NF 或 3NF，把原本依赖其他表的属性字段直接添加到当前表中。最常见的做法，是在订单表中增加用户名、商品名称等字段，避免每次查询都去关联用户表或商品表。派生列则是指通过其他列的值经过较为复杂的计算得出的新列，例如订单总价由单价和数量计算而来，若是简单计算，通常用视图即可解决，但若计算逻辑复杂或查询频繁，则可考虑将其持久化为实体列。

引入冗余列或派生列时，有一个简单的判断标准：大部分读取操作是否都需要用到某个外键关联信息或某个计算值。在记录历史数据（如订单、操作日志）的场景下，为了保证历史记录的完整性和不可变，即使主表的数据后续被修改或删除，也有必要在历史表中冗余存储关键信息的快照。

2. JSON 字段

在很多场景下，JSON字段是对数据库表结构的有利补充。例如，可以在一个字段内，存储一个由多个标签组成的数组，或者存储一个结构化的对象信息。从范式角度看，存储数组违反了第一范式，而存储对象则可能引入传递依赖，违反第三范式。

使用JSON字段的判断标准，在于确认字段内部的值是否仅与当前表记录本身相关，其他表不会直接关联到该JSON字段内部的某个具体值。如果JSON对象或数组内部的值不需要独立查询、更新或作为关联条件，那么用 JSON 存储非常合理，既能保持结构灵活，也能减少关联开销。

（图：使用冗余列、派生列、JSON列的典型表结构）

3. 预连接、预聚合报表

增加冗余列、派生列主要针对有明确筛选条件、范围较小的查询。但对于报表类、分析类的查询，其特点往往是需要扫描大量数据并进行复杂的连接和聚合，无论如何优化都难以避免全表扫描。这时，我们可以参考数据仓库的分层设计思想，构建预连接和预聚合的中间层。通常可以分为以下几层：

数据接入与原始层（ODS）：存放从业务数据库同步过来的原始数据，仅做格式标准化。
数据明细与整合层（DWD）：对原始数据进行清洗、转换，并关联补充必要的字段，形成一份干净、完整的明细数据。
数据轻度汇总层（DWM）：根据常见的报表维度（如按天、按部门、按产品类别），对明细数据进行轻度汇总聚合，形成中间结果。例如，预先计算好每天的销售额、订单数。
数据应用与报表层（APP）：基于汇总层的数据，进一步加工成业务可直接使用的结论性数据。这一层数据通常只会计算一次，保证历史数据不变，以保证对外输出的报表与数据库数据之间的统一。

此处，我们本身就是在设计业务数据库，“数据接入与原始层”就直接对应原始表；“数据明细与整合层”对应冗余列、派生列、查询视图；“数据轻度汇总层”、“数据应用与报表层”才是我们针对报表数据查询需求，需要增加的表。

通过这种分层预计算，将频繁使用的关联统计结果，批量写入，或用计划任务提前计算，在查询时只需扫描轻量级的汇总结果，从而实现了报表查询的及时响应。