数据库 Schema 设计里的「宽表 vs 窄表 + JOIN」之争：你的红线到底画在哪里？

背景

做了 5 年大数据平台，我在不同团队见过同一个问题被讨论至少五次：一张订单表，到底是把商品名、商家名、收货人、支付渠道全冗余进去（宽表），还是只存外键、查询时 JOIN 四张表（窄表）？

两种做法我都深度参与过。宽表那张 1.2 亿行的订单主表，单表 28 个字段，查询 P99 稳定在 5ms；窄表方案那张 8000 万行的订单表，JOIN 四张维度表，同样的业务查询 P99 在 40ms。看起来宽表赢了？但三个月后，商品名改了三个字段、商家合并了一次，宽表的同步任务挂了 47 分钟，数据不一致的工单排了 20 多张。

常见分歧（我至少见过四种流派）

1. 宽表党（"JOIN 就是性能杀手"）：OLTP 场景下 JOIN 是万恶之源，冗余 3~5 个字段换掉 3 次 JOIN，P99 直接从 50ms 降到 5ms。代价是写路径变重（多几张表的同步/更新），但"写少读多"的业务完全能接受。典型场景：订单列表、商品详情页、用户画像宽表。
2. 窄表党（"规范化是底线"）：冗余 = 数据不一致的定时炸弹。商品名改一次，你的宽表同步任务跑多久？中间那 30 秒用户看到的就是脏数据。而且每多一个冗余字段，CRUD 逻辑就多一条"别忘了同步"的隐式约束，新人接手时最容易漏。典型场景：主数据管理、多业务线共享的维度表。
3. 折中派（"核心路径宽、长尾窄"）：高频查询路径上的 2~3 个字段可以冗余（比如订单表的 merchant_name），但低频、多维度、会变化的字段必须走 JOIN。判断标准是"这个字段未来 12 个月会不会被业务方要求改？会 → 不冗余；不会 → 可以冗余"。
4. 反范式 + 物化派：OLTP 主库保持窄表（事务一致性优先），OLAP 报表走独立的宽表（用 CDC / 物化视图 / 离线 ETL 同步），两边各管各的。代价是架构复杂度翻倍，但读写路径彻底解耦。

我的倾向与理由

我属于第 3 种，但有一个硬红线：冗余字段的变更频率 > 月均 1 次 → 不许冗余。

具体判断框架（我在 1 亿行级订单表上验证过的）：

• 能不能冗余：这个字段是"事实"（创建后不变，如订单金额、下单时间）还是"属性"（会变化，如商品名、商家状态）？事实 → 安全冗余；属性 → 慎冗余。
• 冗余后同步成本：如果源表变更走 binlog 订阅同步，延迟通常 < 1s，可以接受；如果是业务代码双写，多一个字段就多一个"忘了更新"的风险点。
• 查询路径占比：如果 80% 的查询只需要 2 个冗余字段，而 20% 的查询需要 JOIN 3 张表，那宽表只解决了 80% 的问题，剩下 20% 还是慢——不如把 JOIN 优化好（覆盖索引、预计算），保持 schema 干净。
• 团队规模：2~3 人的小团队，宽表 + 手动同步能跑；10 人以上多业务线共用一张表，冗余字段的同步逻辑会变成"隐形技术债"，迟早有人改了一个字段忘了同步另一个。

想听大家聊聊

1. 你们团队的订单/交易主表，是宽表还是窄表？冗余了几个字段？同步方式是什么（双写 / CDC / 定时任务）？
2. 有没有遇到过"当初冗余了，后来源表改了字段，宽表同步任务漏更新"的线上事故？怎么发现和修复的？
3. "核心路径宽、长尾窄"这个折中方案，你们怎么界定"核心路径"？是按 QPS 排还是按业务方优先级排？
4. 物化视图 / CDC 同步做宽表这条路，你们用的是什么技术栈？延迟、一致性、回滚怎么保证？
5. 你们团队有没有"禁止冗余字段"的架构红线？还是"看场景"？

欢迎把你们的 schema 设计决策和踩坑经历贴出来，我收集一下大家的判断标准。