Django ORM使用ID列表批量更新时SQL执行缓慢问题排查

问题根源 #

你当前的方案慢主要有两个原因：

1. 先把切片后的QuerySet数据加载到Python内存，再循环收集主键ID，这多了一次不必要的内存IO和循环开销，尤其是数据量较大时，内存加载和遍历都会拖慢速度。
2. pk__in传入1000个ID的列表时，数据库解析这个长列表会产生额外性能损耗，哪怕主键是索引，长IN列表的匹配效率也会下降。

另外你提到的Django不允许对切片QuerySet执行更新，是因为切片对应SQL的LIMIT/OFFSET，而不同数据库对UPDATE搭配LIMIT的支持不一致（比如PostgreSQL早期版本不支持），Django为了跨库兼容性做了限制。

可行解决方案 #

1. 用子查询替代内存收集ID #

不需要把数据拉到Python内存，直接让数据库通过子查询生成需要更新的主键集合，减少一次查询和内存操作：

from django.db.models import Subquery

constant1 = sth
constant2 = sth

# 子查询直接在数据库层面筛选出目标主键
target_pks = Model.objects.filter(...).values('pk')[:nb]

Model.objects.filter(
    pk__in=Subquery(target_pks)
).update(
    field1=constant1,
    field2=constant2,
    ...
)

这种方式只会生成一条带内连接的SQL，所有筛选逻辑都在数据库内完成，避免了Python层面的循环和内存开销，数据库处理子查询的效率远高于处理长IN列表。

2. 直接执行原生SQL（针对特定数据库） #

如果你的项目只兼容某一种数据库（比如MySQL、PostgreSQL 11+），可以绕过Django的QuerySet限制，直接用原生SQL执行带LIMIT的更新：

MySQL示例

from django.db import connection

constant1 = sth
constant2 = sth
batch_limit = nb

with connection.cursor() as cursor:
    cursor.execute("""
        UPDATE your_app_model
        SET field1 = %s, field2 = %s
        WHERE -- 这里填入原filter中的筛选条件
        LIMIT %s;
    """, [constant1, constant2, batch_limit])

PostgreSQL示例

from django.db import connection

constant1 = sth
constant2 = sth
batch_limit = nb

with connection.cursor() as cursor:
    cursor.execute("""
        UPDATE your_app_model
        SET field1 = %s, field2 = %s
        WHERE -- 原filter筛选条件
        ORDER BY pk -- 必须指定排序，PostgreSQL要求LIMIT搭配ORDER BY
        LIMIT %s;
    """, [constant1, constant2, batch_limit])

注意：这种方式要确保筛选条件有合适的索引，避免全表扫描，同时要考虑数据库兼容性，跨库项目不建议用。

3. 分批次更新 #

如果单次更新1000条还是慢，可以拆成多个小批次（比如每次100条），降低单次IN列表的长度，减少数据库的解析压力：

constant1 = sth
constant2 = sth
batch_size = 100
total_count = nb

for offset in range(0, total_count, batch_size):
    target_pks = Model.objects.filter(...).values('pk')[offset:offset+batch_size]
    Model.objects.filter(pk__in=Subquery(target_pks)).update(
        field1=constant1,
        field2=constant2,
        ...
    )

分批次更新还能避免单次更新锁表时间过长，减少对其他业务的影响。

额外优化建议 #

• 检查原filter(...)中的筛选条件是否添加了合适的索引，如果筛选条件没有索引，第一步的查询就会很慢，拖累整个流程。
• 确认主键字段是数据库的主键索引（Django默认会创建，但自定义主键时要注意）。
• 如果开启了DEBUG模式，建议关闭，DEBUG模式会记录所有SQL语句，产生额外的性能开销。

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