Django基类模型默认按PK排序的弊端及Postgres下性能影响探讨

一、性能层面的潜在开销 #

Django文档明确提到：

排序并非无成本；每个排序字段都是数据库必须执行的操作。如果模型有默认排序（Meta.ordering）且不需要，可通过调用无参数的order_by()在QuerySet中移除。

具体到ordering=["pk"]的情况，主要性能问题包括：

• 不必要的索引遍历开销：Postgres的主键默认带B-tree索引，按主键排序会走索引扫描而非全表排序，但索引扫描仍需遍历索引节点、定位数据行，大数据量下IO和CPU消耗会累积。比如全表查询Model.objects.all()时，无排序的全表扫描（Seq Scan）会直接顺序读取数据页，而带主键排序的索引扫描需要在索引和数据页之间跳转，反而更慢。
• 聚合/分组查询的额外负担：执行annotate()或aggregate()时，默认排序会被带入查询，导致数据库先排序再分组，增加无意义的计算步骤。比如统计分类下的数量时，本来可以直接分组，却因主键排序多了一层排序操作。
• 关联查询的连锁开销：反向查询或跨表查询时，默认排序会应用到关联表的QuerySet上。比如查询某作者的所有书籍，即使不需要排序，也会自动加上ORDER BY book.id，多了不必要的排序逻辑。

二、非性能类的隐性问题 #

• 违背QuerySet的惰性预期：所有基于该基类的QuerySet都会强制带上排序逻辑，新手容易忽略这一点，在不需要排序的场景下忘记调用order_by()取消，导致查询逻辑不符合预期。
• 子类排序的灵活性受限：虽然子类可以重写Meta.ordering，但如果子类疏忽未重写，就会继承主键排序，可能导致业务逻辑错误。比如需要按发布时间排序的文章模型，继承基类后会默认按主键排序，不符合需求。
• 分页场景的隐性依赖：Django分页依赖有序QuerySet，基类的主键排序能保证分页正常，但后续若要修改排序规则，需同步调整所有分页相关代码，否则会出现分页结果混乱。

三、Postgres下按主键排序的实际开销 #

Postgres中主键默认带B-tree索引，ORDER BY pk确实能利用索引避免全表排序，但开销并非完全可以忽略：

• 小结果集场景：开销几乎可以忽略，索引扫描的性能和全表扫描差距极小。
• 大结果集场景：索引扫描需要遍历大量索引节点，再去数据页取数据，此时无排序的全表扫描反而更快，因为不需要额外的索引跳转开销。
• 带过滤条件的场景：如果过滤后的结果集很小，主键排序的开销可以忽略；但如果过滤条件宽松、结果集大，排序的额外开销就会显现。

总结 #

基类设置ordering=["pk"]看似安全，实则会带来不必要的性能开销（尤其是大数据量场景），还可能引发隐性逻辑问题。建议仅在具体需要的子类中单独配置默认排序；若必须在基类设置，记得在不需要排序的QuerySet上调用order_by()取消默认排序。

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