SQL一对多关系：采用外键列表是否更具优势？

核心结论 #

主流推荐的第一种方案（Persons表存储owner外键）在性能、可维护性、数据一致性上全面优于第二种方案，你担心的“遍历1000万数据”是对数据库索引机制的误解。

为什么第一种方案不会遍历全表？ #

• 只要给Persons表的owner字段建立索引，数据库查询时会直接通过索引定位到该用户对应的所有人物记录，完全不需要全表扫描。
• 你设计的复合主键(owner, number)，在InnoDB这类主流引擎中会自动生成聚簇索引，这个索引的结构是按owner分组、再按number排序的。查询某用户的人物时，数据库能直接定位到该owner对应的索引区间，快速取出目标数据，哪怕是1000万级的数据量，响应速度也能达到毫秒级。

第二种方案（Users表存人物UUID列表）的问题 #

• 性能反而更差：
  • 查询用户的人物时，需要先从Users表取出UUID列表，再用IN语句去Persons表批量查询。如果用户有N个人物，数据库需要执行N次索引查找（或合并查找），当人物数量较多时，这个过程比直接查询owner索引慢得多。
  • 列表字段（比如JSON类型）无法建立有效的二级索引，像“查询所有用户年龄大于30的人物”这类关联查询几乎无法高效实现。
• 数据一致性无法保障：
  • SQL的外键约束无法作用于列表内的UUID，没法保证列表里的UUID一定存在于Persons表，也没法在Persons表记录被删除时自动更新Users表的列表，很容易出现脏数据或无效数据。
• 维护成本极高：
  • 添加、删除人物时，需要先修改Users表的列表字段（比如JSON数组的追加/删除），再操作Persons表，步骤繁琐且容易出现并发更新冲突。
  • 列表字段的存储格式（如JSON）在不同数据库中处理逻辑不一致，后续迁移或扩展会遇到兼容性问题。

优化建议 #

• 依赖复合主键(owner, number)的聚簇索引已经能满足基本查询需求，若要进一步优化，可以根据常用查询字段建立覆盖索引，比如(owner, name, age)，这样查询用户人物的基本信息时无需回表，性能更优。
• 分页查询（比如只取用户的前5个人物）时，直接用WHERE owner = ? LIMIT 5即可，复合主键的结构天然支持高效分页。

内容的提问来源于stack exchange，提问作者Ein Google-Nutzer