多公司动态维度模型的两种SQL设计方案有效性咨询

方案1：内置维度列 #

• 性能表现：300k数据量下查询速度极快。维度值直接存储在事实表中，无需关联查询，聚合、过滤操作均可基于单表完成；只要给ClientId与维度列建立组合索引，即使跨企业查询或维度过滤，性能也不会有明显瓶颈。
• 优势：实现逻辑简单，开发和维护成本低；查询逻辑直接，无需处理多表关联的复杂逻辑；针对最多3个维度的场景，固定列数不会造成过度的数据冗余。
• 局限性：维度数量被固定为3，若后续企业需求超过这个数量，扩展成本极高；维度值的数据类型必须统一，若不同企业同维度列需要不同类型，处理起来会很繁琐；维度含义完全依赖配置表，可读性差，排查问题时需额外关联配置表确认含义。

方案2：独立维度表 #

• 性能表现：300k数据量下，只要给RecordId、ClientId、Type建立合适的复合索引，关联查询的性能完全能满足业务需求。单条业务记录的多维度数据以行形式存储，聚合时需分组，相比方案1的单表聚合会稍慢，但在300k量级下差异微乎其微，用户几乎感知不到。
• 优势：维度数量灵活，不受3个的限制；维度类型可通过Type区分存储（不同Type的Value可适配不同数据类型，或用字符串统一存储但实际含义不同）；维度含义通过Type直接标识，可读性更好，无需额外查询配置表。
• 局限性：每次查询业务数据都需要关联维度表，查询逻辑更复杂；若一条业务记录有3个维度，维度表会对应3条记录，数据量会是业务表的2-3倍，但300k业务数据对应的维度表最多900k，这个量级在数据库中完全可控；需要维护更多索引，确保关联字段的查询效率。

总结 #

在数据量不超过300k的场景下，两种方案均能有效运行：

• 若确定维度数量永远不会超过3，且希望开发和查询尽可能简单，优先选择方案1。
• 若需保留维度数量扩展的可能性，或对维度含义的可读性要求更高，方案2完全可行，性能不会成为瓶颈。

内容的提问来源于stack exchange，提问作者Andrius