字段设计应平衡业务需求、数据完整性、查询效率和维护成本，而非单纯减少数量；需清理冗余低价值字段，按语义建模，避免强行合并或过度细分。
表字段不是越少越好，而是要平衡业务需求、数据完整性、查询效率和维护成本。
字段太少反而增加复杂度
为了“精简”而强行合并字段，比如把地址拆成“地址1”“地址2”“地址3”，或把姓名和昵称合并在一个字段里，会导致：
- 查询时需要频繁用字符串函数解析，性能下降
- 无法对特定语义部分（如省/市）建立索引或约束
- 业务逻辑被迫下沉到应用层，容易出错且难统一
- 违反第一范式，后续扩展（如支持多地址、多姓名类型）代价极高
真正该精简的是冗余和低价值字段
以下字段值得优先清理：
- 长期为 NULL 且无明确业务含义的字段（如“备用字段2”）
- 可通过其他字段计算得出的冗余列（如“年龄”——应存“出生日期”，避免每日更新）
- 被弃用但未下线的历史字段（影响可读性和 ORM 映射）
- 过度细分的枚举字段（如把“订单状态”拆成10个布尔字段，不如用单个状态码+字典表）
合理设计的关键是“按语义建模”，不是按数量取舍
例如用户信息表：
- 应该有 user_id、name、email、phone、created_at、status 等独立字段——语义清晰、可索引、易校验
- 不应把 email + phone + wechat_id 合并为 contact_info JSON 字段，除非这些字段极少单独查询或过滤
- 若真有多值联系人（如多个手机号），应拆到关联表，而不是堆在主表加 contact1/contact2/... 字段
性能瓶颈通常不在字段数量，而在访问模式
100 个字段的宽表，只要常用查询只查其中 3 列，且这 3 列有合适索引，性能未必差；反之，5 个字段的表若每次都要 SELECT *、没索引、关联太多，照样慢。关键看
- 高频查询涉及哪些字段？是否覆盖索引可用？
- 写入频率高不高？字段多会加大日志体积和锁竞争
- 是否需要归档或分区？宽表会让分区策略更难设计
不复杂但容易忽略：字段设计的本质，是让数据结构匹配业务事实的表达方式，而不是追求表面上的“简洁”。
