MySQL多对多关系的无限扩展：单表实现可行性及相关疑问

先说结论：多对多对多甚至无限层级关系能在单表实现，但这绝对是个糟糕的选择，下面逐个拆解你的问题：

1. 能不能单表实现？ #

可以，但实现方式要么是硬加字段（比如三方多对多就加a_id、b_id、c_id），要么是用JSON/数组类型存一批关联ID（比如无限层级时存related_ids数组）。但这两种方式都是牺牲数据库特性换“单表”，完全得不偿失。

2. 理论上的问题 #

这种做法从数据库设计的根上就有问题：

• 违反范式：直接打破第三范式，数据冗余会疯狂滋生。比如同一个A和B关联10个C，a_id和b_id就要重复存10次，后续改关联时要同步更新所有重复行，稍有不慎就出问题。
• 扩展性为0：无限层级的话，你总不能一直加字段吧？用JSON存的话，关系型数据库的索引、外键、约束这些核心优势全废了，查询时还要解析JSON，性能暴跌。
• 数据完整性无法保障：外键约束没法加在JSON/动态字段上，全靠业务代码控数据，很容易出现脏数据（比如存了不存在的关联ID）。
• 查询逻辑极度复杂：比如查某个A关联的所有C，用连接表只需要几次JOIN，但单表要么写一堆重复条件，要么写JSON解析的复杂SQL，维护成本直线上升。

3. 大量数据重叠的致命影响 #

数据重叠（冗余）带来的问题绝对是致命的：

• 存储成本爆炸：冗余数据占满磁盘，备份、迁移的时间和资源成本翻倍。
• 性能雪崩：查询时要扫描大量重复行，索引命中率极低；更新操作要修改N条重复数据，锁表时间拉长，并发场景下直接拖垮服务。
• 一致性风险：只要有一处冗余数据没同步更新，就会出现数据不一致，排查的时候要翻遍所有重复行，简直是噩梦。

4. 单表平均允许多少字段？ #

没有统一的“平均”数值，不同数据库的硬上限和实际可用量差异很大：

• MySQL：默认最大字段数是4096，但受InnoDB行大小限制（默认约65535字节），实际能用的字段数远低于这个数——如果用的是CHAR、INT这类固定长度类型，可能几百个字段就到顶了。
• PostgreSQL：理论支持最多1600个字段，但同样受行大小限制，超过一定长度会用TOAST存储大字段，但性能会明显下降。
• 但从业务角度说，单表字段超过20-30个就已经算臃肿了，维护和查询都会变得麻烦，更别说用来存多层级关联了。

内容的提问来源于stack exchange，提问作者dontknowhy