Django模型可定义的字段数量存在哪些限制？

以下讨论基准为Ubuntu Server上各组件最新LTS等效版本：Django 4.2 LTS、SQLite 3.37+（Ubuntu 22.04 LTS默认源内置版本）、PostgreSQL 14 LTS。

代码层面限制 #

Django框架本身没有写死单模型的字段数量硬阈值，翻4.2 LTS源码中负责模型元数据处理的Options类，也没有对字段列表长度做任何拦截校验，但实际运行中会遇到几个明确的软约束：

• 启动性能约束：每个模型字段在项目启动阶段都会完成描述符生成、信号注册、校验规则绑定、反向关联映射等初始化流程。单模型字段数超过500时，单模型加载耗时会从毫秒级涨到秒级，整个项目启动时间会拉长到分钟级，不管是开发环境热重载还是生产环境worker重启都会变得极难使用。
• 表单层性能约束：如果使用Django Admin、ModelForm等组件，单模型字段数超过200时，表单渲染、参数校验、权限判断的耗时会涨到秒级，完全无法满足普通接口的响应要求。
• ORM运行开销约束：字段越多，ORM生成查询、写入SQL的解析成本越高，生成的SQL语句越长，除了会拉高数据库侧的SQL解析开销，极端场景下还可能触发代理、网关层的请求长度限制。
• 注意：ManyToManyField不会在主模型对应的数据表中生成列，不计入主表字段的数量统计；ForeignKey、OneToOneField会生成实际的数据库列，需要计入统计。

数据库层面限制 #

代码层的软限制一般远早于数据库的硬限制触发，两类主流数据库的约束如下：

SQLite #

• 硬上限：Ubuntu默认源编译的SQLite 3.37+版本，单表最大列数由编译参数SQLITE_MAX_COLUMN控制，默认值为2000。如果自行编译SQLite修改该参数，理论最高可以支持到32767列，但这个量级下性能已经完全不可用。
• 实际软约束：SQLite采用行式存储，且没有独立的行外大字段存储机制，列数超过100时普通查询的解析开销就会明显上升，超过300列后简单SELECT查询的性能会比百列以内的表慢数倍；列数接近1000时，单条插入操作的耗时会从微秒级涨到毫秒级，完全不具备生产可用性。
• 额外约束：SQLite单条联合索引最多支持32列，不影响总字段数上限，但设计联合索引时需要注意。

PostgreSQL #

• 硬上限：PostgreSQL 14的单表列数硬上限为1600，这个值是源码层面写死的硬约束，由元组头的属性ID位长度决定，无论怎么修改配置参数都无法突破。如果Django模型字段数超过这个值，执行migrate时会直接触发建表报错。
• 实际软约束：PostgreSQL默认数据页大小为8KB，虽然超长字段会自动通过TOAST机制存到行外，但当列数超过200时，查询优化器生成执行计划的开销、行数据解析开销、更新操作的写放大都会明显上升；列数超过500时，哪怕是主键查询都会出现可感知的性能下降，PostgreSQL官方性能指南也不建议单表列数超过200-300区间。
• 额外约束：和SQLite一致，PostgreSQL单条联合索引最多支持32列。

实际使用建议 #

• 普通业务场景尽量把单模型字段数控制在50以内，超过100时就应该评估优化方案：比如用JSONField存储非结构化的扩展属性、通过一对一关联做垂直分表、拆分独立的关联表存储稀疏属性。
• 不要尝试触碰数据库的字段数硬上限，哪怕能成功建表，后续的查询、写入、运维、迭代成本都会高到无法接受。
• 如果业务确实需要存储大量动态属性，优先考虑EAV（实体-属性-值）模型或者专门的宽表存储方案，不要直接给主模型叠加数百个字段。

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