SQL中拆分字段生成子表本质是解决“可扩展字段”的灵活性与规范性矛盾，通过将动态属性剥离至独立子表并建立关联，既保持主表结构稳定，又支持灵活增删字段类型。
SQL中拆分字段生成子表，本质是为解决“可扩展字段”带来的灵活性与规范性矛盾。核心思路是把动态、不确定的附加属性，从主表中剥离，用关联关系存到独立子表，既保持主表结构稳定，又支持随时增删字段类型。
为什么不能直接在主表加一堆预留字段？
预留字段（如 ext1~ext10、custom_field_json）短期省事，长期会带来问题：
- 字段语义丢失：ext3 到底存的是折扣率还是生效时间？靠文档或代码注释维系，极易出错
- 查询困难：无法建有效索引，JSON 字段查值要依赖函数（如 MySQL 的 JSON_EXTRACT），性能差且难优化
- 约束失效：无法对“用户等级”字段加 CHECK 或外键，数据质量失控
- 变更僵硬：新增一个必填业务字段，就得 ALTER TABLE，影响大表在线变更
典型可扩展字段子表设计（EAV 或轻量级变体）
不推荐全量 EAV（Entity-Attribute-Value），太重；常用更可控的“属性组+键值对”方式：
主表（user）： id, name, phone, created_at
扩展字段定义表（field_def）： id, code, label, data_type, is_required, sort_order
扩展值子表（user_field_value）： user_id, field_id, value_string, value_number, value_date, value_boolean
说明：
HISUI 前端框架基础开发指南。HISUI 是基于 easyui 二次开发的 jQuery UI 组件库，专为医疗信息系统设计。当涉及 HISUI 组件开发、jQuery easyui 表格/表单/布局/窗口、医疗系统前端页面编写时使用此 skill。 涵盖 40 个组件的官方文档参考，支持声明式与编程式两种初始化方式，提供 $cm/$m 数据访问方法。
- field_def 预先配置好业务允许的扩展字段（如 “会员等级”、“首次购买渠道”、“是否开启推送”）
- user_field_value 按需为每个用户存实际值，用多个 typed 列避免全用 text 带来的类型混乱和查询低效
- 联合索引 (user_id, field_id) 支持快速拉取某用户所有扩展值
查询时怎么写才不慢？
避免 N+1 和全表扫描。关键技巧：
- 用条件聚合一次性查多个字段：
SELECT u.id, u.name,
MAX(CASE WHEN f.code = 'member_level' THEN v.value_string END) AS member_level,
MAX(CASE WHEN f.code = 'channel' THEN v.value_string END) AS channel
FROM user u
LEFT JOIN user_field_value v ON u.id = v.user_id
LEFT JOIN field_def f ON v.field_id = f.id
WHERE f.code IN ('member_level', 'channel')
GROUP BY u.id, u.name - 高频查询字段可冗余到主表（如 member_level），用触发器或应用层同步，读写分离场景下很实用
- 对 value_string 建前缀索引（如 INDEX idx_val_str (value_string(50))），适合模糊搜或等值查短文本
什么时候该用 JSON 字段替代子表？
不是所有扩展都值得建子表。以下情况 JSON 更合适：
- 纯前端展示用、不参与查询/统计/校验的配置项（如用户界面布局偏好）
- 字段极少变化、生命周期短（如活动页临时参数）
- 团队小、迭代快，暂无精力维护多表关联逻辑
但务必约定 key 命名规范（如 snake_case）、加 JSON Schema 校验（PostgreSQL 支持 jsonb_path_exists），并避免在 WHERE 中对 JSON 内部字段做范围查询。
基本上就这些。可扩展字段设计不是非此即彼，关键是根据查询频率、一致性要求、团队运维能力做取舍。子表稳但稍重，JSON 轻但易散，中间态（如按业务域分几张轻量扩展表）往往最实用。
