字段设计应依语义独立性、查询需求、维护成本和扩展性权衡：语义混杂须拆分（如VIP标识拆为等级/年份/序号），高频原子查询需独立字段（如log_date），更新频率或约束差异大则分字段，稳定结构优先拆分，不确定场景可暂用带校验的JSON。
字段该拆分还是合并，关键看数据语义、查询场景和维护成本。不是越细越好，也不是越粗越省事，得围绕“怎么用”来设计。
看业务语义是否独立
如果一个字段实际代表多个无关联的含义，强行合并会损害可读性和约束力。比如把“用户身份标识”存成 "VIP_2023_001"，看似一个字段，实则混了等级、年份、序号三层信息——无法建索引查VIP用户，不能校验年份合法性，修改序号还得字符串操作。
- 建议：等级、注册年份、序列号应拆为 user_level、reg_year、serial_no 三个字段
- 反例：“地址”字段若长期只做展示、从不按省/市过滤或统计，就没必要拆成 province/city/district
看高频查询是否需要原子访问
经常要单独 WHERE 或 ORDER BY 某部分值？那这部分就得独立成字段。比如日志表里 log_time 存的是完整时间戳，但业务总查“今天新增多少条”，这时加个 log_date（DATE 类型）字段能避免函数索引或全表计算。
- 拆分前提：该子项有独立查询、排序、分组、索引需求
- 合并前提：始终以整体参与查询，且拆开后反而增加 JOIN 或冗余存储（如 JSON 中的固定结构小字段）
看变更频率和一致性要求
同一逻辑实体中，如果各子项更新频率差异大，或需独立维护约束（如手机号要唯一、邮箱要格式校验），合并会导致锁粒度变粗、校验逻辑耦合、迁移困难。
- 例如：用户联系信息含手机号、邮箱、微信ID，三者可能分别由不同业务流程更新，应分字段并各自加约束
- 又如：配置项中“开关状态+生效时间+备注”常一起修改，且极少单独查询，合并在一个 JSON 字段反而更灵活
看扩展性与演进成本
预判未来半年到一年内是否可能新增同类属性？是否要支持多语言、多版本、多租户？合并字段（尤其 JSON/TEXT）短期快，但后期加索引、改结构、写同步脚本都更重。
- 稳定结构 + 明确增长路径 → 优先拆分为明确字段
- 高频变动、schema 不确定、读多写少 → 可暂用 JSON，但需配套定义校验规则和访问函数
- 别为了“看起来整洁”把所有字符串都塞进一个 field_data 字段——那是放弃数据库的基本能力
