Django REST Framework中QuerySet Union与Q查询的性能对比及优化

一、Union与Q查询的性能差异 #

Union实现的性能瓶颈 #

• 生成多段SELECT语句通过UNION拼接，数据库需执行多个独立子查询后合并结果集，大数据量下合并阶段会显著增加RDS的CPU与内存开销。
• 默认union会自动去重（等效于UNION DISTINCT），额外增加数据库的去重计算成本。
• 原代码中通过先查询关联模型（如modelA_results）再用__in筛选，会生成嵌套子查询，进一步增加数据库执行复杂度。

Q查询的性能优势 #

• 生成单条SELECT语句，用OR连接所有筛选条件，数据库查询优化器可更高效地执行计划，避免多结果集合并的开销。
• 支持直接跨关联模型筛选（如Q(modelA__raw_data__icontains=search_query)），无需提前查询关联模型的ID列表，减少不必要的子查询。
• 去重逻辑可通过distinct()按需触发，比Union的强制去重更灵活。

在小数据量场景下两者差异不明显，但数据量达到万级以上时，Q查询的执行效率通常是Union的2-5倍，且RDS负载更低，间接降低EC2的等待时间与CPU占用。

二、最优性能实现方案 #

1. 优化Q查询写法 #

避免冗余子查询，直接使用跨关联的Q条件组合，示例代码如下：

from django.db.models import Q
from rest_framework import viewsets

class modelMainViewSet(viewsets.ModelViewSet):
    def get_queryset(self):
        search_query = self.request.query_params.get('search_query')
        if not search_query:
            return modelMain.objects.all()
        
        query_filters = Q()
        # 主模型自身字段筛选
        if self.request.query_params.get('description') == 'used':
            query_filters |= Q(description__icontains=search_query)
        if self.request.query_params.get('modelMain_subject') == 'used':
            query_filters |= Q(subject__icontains=search_query)
        
        # 关联模型筛选
        if self.request.query_params.get('modelA') == 'used':
            query_filters |= Q(modelA__raw_data__icontains=search_query)
        if self.request.query_params.get('modelB') == 'used':
            # 多对多关系直接通过双下划线关联字段
            query_filters |= Q(modelB__name__icontains=search_query)  # 替换为modelB实际字段名
        if self.request.query_params.get('modelC') == 'used':
            query_filters |= Q(modelC__value__icontains=search_query)
        
        # 按需去重，避免重复结果
        return modelMain.objects.filter(query_filters).distinct()

2. 数据库索引优化 #

通配符icontains（%xxx%）无法利用普通B树索引，需针对性优化：

• 全文索引：优先使用数据库原生全文索引，PostgreSQL可通过Django的SearchVector/SearchQuery实现，MySQL可直接创建全文索引并使用search查询，性能比icontains提升10倍以上。
• 字段预处理：将需要搜索的字段统一转为小写存储，用contains替代icontains，可利用字段的B树索引（仅适用于前缀/后缀通配符场景）。
• 关联字段索引：确保所有外键、多对多关联字段存在默认索引（Django自动创建），减少关联查询的JOIN开销。

3. 降低EC2负载的措施 #

• 合理分页：使用DRF的PageNumberPagination限制每页数据量（如每页20条），避免一次性加载大量数据占用EC2内存。
• 减少N+1查询：用select_related（外键）、prefetch_related（多对多）预加载关联模型数据，减少数据库查询次数，降低EC2的CPU开销。
• 缓存高频结果：用Redis缓存热门搜索关键词的查询结果，避免重复查询数据库，同时降低EC2与RDS的负载。

4. 修复代码中的错误 #

原Union代码中modelC部分存在逻辑错误：

# 错误写法
queryset = queryset.union(modelMain.objects.filter(modelC__in=modelC).distinct())
# 正确写法
queryset = queryset.union(modelMain.objects.filter(modelC__in=modelC_results).distinct())

总结 #

Q查询在性能、兼容性（适配Django Filters）上均优于Union实现，是此类场景的最优选择。结合全文索引、合理分页与缓存策略，可同时降低EC2的CPU/内存占用与RDS的负载。

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