Azure部署的Django1.11.0+SQL Server站点查询性能及视图耗时优化咨询

嘿，我之前在Azure上部署Django项目连接SQL Server时，也碰到过这种「查询快但视图响应慢」的情况，这种差距通常藏着ORM、网络或者应用层的隐形开销，咱们一步步来排查优化：

一、先揪出ORM和数据处理的隐形开销 #

• 排查N+1查询漏网之鱼：哪怕你已经用了select_related/prefetch_related，有时候嵌套的反向关联或者多对多关系还是会偷偷发起额外查询。用django-debug-toolbar的Queries面板（Django1.11支持这个工具），看看有没有重复执行的小查询，把这些关联用prefetch_related批量拉取，比如Model.objects.prefetch_related(Prefetch('related_model', queryset=RelatedModel.objects.only('id', 'name')))，只拉需要的字段。
• 砍掉模型实例的冗余开销：1444条记录如果都实例化成Django模型对象，初始化、字段验证这些步骤会占不少时间。如果是返回JSON数据，直接用values()/values_list()获取字典/元组，跳过模型实例创建，比如Model.objects.filter(...).values('id', 'name', 'related_field__value')，再把这些字典序列化成JSON，比用DRF Serializer处理模型实例快很多。
• 序列化优化：如果必须用序列化器，试试DRF的ListSerializer批量处理，或者用更轻量的库比如orjson替代默认的JSON序列化器（需要适配Django的响应格式），序列化大量数据时速度提升很明显。

二、排查Azure部署的网络与资源瓶颈 #

• 缩小Web应用与SQL Server的网络距离：如果你的Web App和SQL Server不在同一个Azure区域，跨区域的网络往返延迟会被放大，尤其是传输大量数据时。把两者放到同一个区域，或者配置VNet peering让它们在同一个虚拟网络内，减少公网传输的损耗。
• 检查App Service的资源上限：如果用的是Free/Basic层的App Service，CPU或内存不足会导致处理数据时频繁上下文切换。去Azure Portal看App Service的Metrics面板，观察CPU使用率、内存占用是不是接近100%，临时升级到Standard层测试一下，性能如果明显提升，就说明是资源不够的问题。

三、优化请求处理的中间件与模板 #

• 砍掉不必要的中间件：打开项目的settings.py，看看MIDDLEWARE里有没有调试用的、日志用的或者第三方冗余中间件（比如开发环境用的DebugToolbarMiddleware），生产环境直接注释掉，每个中间件都会在请求/响应流程里插一脚，累加起来时间很可观。
• 模板渲染提速：如果是返回HTML页面，渲染1444条记录的循环会拖慢速度。试试用{% load cache %}把列表片段缓存起来，比如{% cache 300 record_list %}{% for record in records %}{{ record }}{% endfor %}{% endcache %}；或者换成Jinja2模板引擎，它的循环渲染效率比Django默认模板高不少。

四、SQL Server驱动与数据库细节优化 #

• 升级并配置合适的ODBC驱动：确保用的是最新版的django-pyodbc-azure驱动，并且在数据库连接的OPTIONS里配置最优参数，比如：

  DATABASES = {
      'default': {
          'ENGINE': 'sql_server.pyodbc',
          'NAME': 'your_db',
          'USER': 'user',
          'PASSWORD': 'pwd',
          'HOST': 'server.database.windows.net',
          'PORT': '',
          'OPTIONS': {
              'driver': 'ODBC Driver 17 for SQL Server',
              'MARS_Connection': 'Yes',
              'Encrypt': 'Yes',
              'TrustServerCertificate': 'No',
              'CharSet': 'UTF8',
          },
      }
  }
  

  旧驱动在数据传输和编码处理上效率很低，换新版驱动能减少数据传输的耗时。
• 确认索引真正生效：虽然查询显示1.2秒，但可以在SQL Server里执行相同的查询，查看执行计划，确认过滤、排序的字段都有对应的索引。比如如果视图里用了order_by('create_time')，就给create_time字段加索引，避免数据库做全表扫描后再排序。

五、用缓存彻底跳过重复工作 #

• 视图级缓存：如果视图内容不是实时更新的，直接用Django的缓存装饰器：

  from django.views.decorators.cache import cache_page
  
  @cache_page(60 * 15)  # 缓存15分钟
  def your_view(request):
      # 视图逻辑
  

  把Azure Redis Cache配置成Django的缓存后端，比默认的内存缓存更稳定，适合生产环境。
• 查询集缓存：如果数据更新不频繁，把查询结果缓存起来，比如：

  from django.core.cache import cache
  
  def your_view(request):
      records = cache.get('your_records_key')
      if not records:
          records = list(Model.objects.filter(...).values('id', 'name'))
          cache.set('your_records_key', records, 60 * 10)  # 缓存10分钟
      # 后续处理
  

六、精确 profiling 定位瓶颈 #

如果上面的方法都没解决，就用cProfile做精确分析：

python -m cProfile -o profile_stats.py manage.py runserver 0.0.0.0:8000

然后用pstats分析结果：

import pstats
stats = pstats.Stats('profile_stats.py')
stats.sort_stats('cumulative').print_stats(20)

看看视图函数里哪一行代码耗时最长，是序列化、循环处理还是某个自定义函数，精准打击瓶颈。

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