宽表与窄表是两种数据组织策略：窄表遵循三范式、字段少、冗余低，适合OLTP高并发事务；宽表反范式、字段多、冗余高，适合OLAP分析查询，读快写慢，二者常混合使用。
宽表和窄表本质是两种不同的数据组织策略，核心区别在于字段数量、数据冗余程度以及适用场景，不是简单“多列 vs 少列”能概括的。
字段结构与设计哲学
窄表遵循数据库三范式，字段精简，主键明确，靠外键关联其他表。比如用户表只存 user_id、name、email；地址单独建 address 表，用 user_id 关联。数据不重复，更新一处即生效。
宽表则反其道而行：把多个业务实体（如用户、订单、商品、地区）相关字段合并到一张表里。字段可能达几十甚至上百个，明显违背范式，但换来的是单表可查全量上下文。
典型例子：
– 窄表组合：users + orders + products + order_items
– 宽表形式：wide_order_fact 包含 order_id、user_name、user_city、product_category、price、order_time、is_paid、coupon_used 等 40+ 字段
读写性能表现差异
宽表适合读多写少：一次 SELECT 就拿到报表所需全部字段，免 JOIN、免子查询，分析类 SQL 更简洁，BI 工具直连友好。
窄表更适合高并发事务：插入/更新快（影响范围小），锁粒度细，不易因冗余字段引发一致性问题。比如修改用户手机号，只需改 users 表一行；宽表中若 10 万订单记录都冗余了该手机号，就需批量更新或触发同步逻辑。
实际中要注意：
• 宽表 avg_row_length 超过 100 字节时，IO 压力会上升，可能拖慢查询
• 单条宽表记录过大（如含 TEXT/BLOB 或大量 VARCHAR），容易导致页分裂、磁盘碎片
维护成本与扩展性
窄表扩展灵活：加一个新属性（如用户兴趣标签），新增 tags 表或 user_profiles 表即可，不影响原有结构和业务 SQL。
宽表改动代价高：新增一列可能涉及全表 DDL（尤其大表），历史数据要补值，ETL 流程、下游应用、权限配置都要同步调整。字段超 50 个后，开发查字段、写 SQL、排查问题的成本明显上升。
常见信号提示该拆分宽表：
• ALTER TABLE 频繁失败或耗时过长
• SHOW TABLE STATUS 显示 Data_free > 0（存在碎片）
• 某些字段 NULL 率长期高于 80%，说明实际业务并未覆盖该维度
怎么选？看场景再决定
OLTP 系统（如电商下单、支付、客服工单）——优先窄表。强调事务一致性、写入吞吐、快速响应。
OLAP 场景（如用户行为分析、销售日报、风控模型特征表）——宽表更合适。用存储空间和更新复杂度，换查询速度和开发效率。
现实中常混合使用：核心交易库用窄表保证健壮性，每日同步生成宽表视图或物化宽表用于分析。关键不在“非此即彼”，而在清楚每张表承担的角色。
