多租户场景下支持UDF维度的MySQL OLAP数仓模型设计咨询

结合你当前的技术栈（MySQL做隔离的OLAP库、现有事实表为全反范式宽表）和使用需求（UDF用于过滤、分组聚合），优先选择预留自定义列的宽事实表方案，EAV结构在该场景下弊远大于利，具体分析和最佳实践如下：

两种方案的适配性对比 #

预留自定义列方案（推荐） #

• 架构改造成本极低：完全匹配你当前的反范式事实表设计，ETL同步逻辑不需要做核心调整，仅需要增加租户UDF到预留列的映射逻辑即可
• 查询性能有保障：MySQL对单列的过滤、分组、聚合优化非常成熟，不需要额外关联表，直接在事实表上就可以走索引查询，完全满足分析类场景的响应要求，大表聚合性能比EAV结构高一个数量级以上
• 运维难度低：表结构稳定，不需要随租户新增UDF频繁改表，空值列的存储开销在MySQL中可以忽略不计
• 唯一的限制是单租户可用UDF数量有上限，但可以通过元数据映射解决，预留足够的列即可覆盖绝大多数租户的需求，极端情况可以单独处理。

EAV结构（不推荐） #

• 仅有的优势是支持无限数量的自定义字段，不需要提前预留列
• 性能缺陷非常突出：只要涉及2个及以上UDF的过滤、聚合操作，就需要多次关联EAV表，大表关联在MySQL中的性能会急剧下降，完全无法满足分析类查询的响应要求
• 开发和维护成本高：所有涉及UDF的查询都需要动态拼接关联逻辑，复杂度高容易出BUG，存储成本也比宽表方案高3~5倍

适配你的场景的最佳实践 #

• 提前做UDF配额规划：根据用户分层预留足够的列，常规配置可以参考：预留15个字符串类型列、10个数值类型列、5个日期类型列，足够覆盖95%以上的中小租户需求，高级租户可以单独扩容配额
• 新增租户UDF元数据表：表结构参考 (tenant_id, udf_display_name, udf_type, mapping_column)，用来记录每个租户的自定义字段名称和事实表预留列的对应关系，用户操作时完全感知不到底层的预留列逻辑
• 针对性做查询优化：给高频使用的预留列建单列或联合索引，ETL同步时对高频分组的UDF做预聚合处理，进一步提升查询性能
• 极端场景特殊处理：如果有极少数租户需要超量自定义字段，单独为这部分租户构建独立的自定义宽表，和主事实表做关联即可，不要为了少数需求调整整体架构。

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