宽表应按业务语义、访问频次和更新节奏拆分：剔除冗余低频字段，垂直拆分为orders主表及order_customer、order_items等附表，冷热字段物理分离，并用物化视图或汇总表替代实时JOIN。
宽表字段过多会显著拖慢SQL报表的执行效率，尤其在数据量大、并发高或需要频繁JOIN的场景下。拆分宽表不是简单删字段，而是按业务语义、访问频次和更新节奏做合理解耦。
识别冗余与低频字段
先分析报表SQL中实际用到的字段，剔除长期未被引用的列（如历史遗留的备注字段、已下线功能的扩展字段）。可用数据库审计日志或查询计划中的列访问信息辅助判断。重点关注：
- 仅在个别报表中出现、且不参与WHERE/GROUP BY/JOIN条件的字段
- TEXT、JSON、BLOB等大字段，即使只查1行也会拉高I/O和内存开销
- 计算型字段（如“销售额=单价×数量”），应移至应用层或视图中动态生成
按业务域垂直拆分主附表
将宽表按核心实体（如订单、用户、商品）及其附属属性分离。例如原订单宽表含客户信息、收货地址、商品明细、促销规则、物流状态等，可拆为：
- orders（主表）：订单ID、下单时间、状态、总金额等强一致性字段
- order_customer：客户ID、等级、标签等用户维度信息
- order_items：商品ID、数量、单价等明细，支持一对多
- order_logistics：运单号、承运商、预计送达时间等物流侧字段
拆分后，常规报表只JOIN必需的附表，避免全量加载无关数据。
冷热分离：高频字段保主表，低频大字段单独存
对访问频率差异大的字段，采用物理分离策略。例如用户表中“头像URL”“个人简介”“第三方授权信息”极少用于统计，但体积不小：
- 保留user_basic（用户ID、手机号、注册时间、状态）作为报表主查询表
- 将非统计类字段放入user_profile，通过LEFT JOIN按需加载
- 对超大文本或二进制字段，可考虑对象存储+外键引用，数据库只存路径
用物化视图或汇总表替代实时宽表JOIN
若某些报表必须呈现“用户+订单+商品+地域”多维聚合结果，且响应要求高，不建议每次实时JOIN宽表。可：
- 每日/每小时跑ETL任务，预计算常用维度组合（如“各省各品类月度订单数”），存入轻量汇总表
- 使用数据库物化视图（如PostgreSQL 9.4+、Oracle、Doris）自动维护聚合结果
- 对实时性要求不高的报表，直接查汇总表，字段精简、索引高效、扫描行数少
