Django开启SQL日志与请求耗时分析方法

本文深入解析了在 Django 中精准开启 SQL 日志（含参数与执行耗时）及 HTTP 请求总耗时监控的实战方法：通过正确配置 `LOGGING` 中 `'django.db.backends'` 的 DEBUG 级别日志器并指定处理器，可实现实时、带参的 SQL 输出（注意 SQLite 驱动限制）；借助置于中间件链最前端的 `time.perf_counter()` 计时中间件，能毫秒级捕获真实请求耗时；同时郑重警示——生产环境严禁开启 SQL 日志，因其引发的日志 I/O 开销会导致响应延迟成倍增长，应优先采用数据库原生性能分析工具。文中还点破了常见误区，如 DEBUG=False 下日志配置完全失效、日志干扰计时精度等关键细节，助你避开踩坑、高效定位性能瓶颈。

怎么让 Django 打印每条 SQL 查询（含参数和耗时）

默认情况下，Django 的 DEBUG=True 只把 SQL 记进 connection.queries，不输出到终端或文件。要实时看到带参数、带执行时间的原始 SQL，得配日志处理器。

关键不是改 settings.py 里的 LOGGING 字段本身，而是确保它覆盖了 django.db.backends 这个 logger，并设为 DEBUG 级别：

• 必须启用 'django.db.backends': {'level': 'DEBUG'}，漏掉这个 key 就完全没输出
• 如果用了第三方数据库驱动（比如 psycopg2），SQL 日志仍走这个路径，不用额外配底层驱动日志
• 注意：只有在 DEBUG=True 时，django.db.backends 才会记录 SQL；生产环境设 DEBUG=False 后，这部分日志自动关闭，无法靠日志配置强行打开

示例片段（LOGGING 中）：

'django.db.backends': {
    'handlers': ['console'],
    'level': 'DEBUG',
    'propagate': False,
},

Django 单次 HTTP 请求的总耗时怎么精确统计

Django 本身不提供请求级计时器，但可以用中间件 + time.time() 或 time.perf_counter() 拿到毫秒级精度。重点不是“怎么写”，而是“在哪插、怎么避免干扰”。

• 必须放在中间件列表最前面（即 MIDDLEWARE[0]），否则可能漏掉认证、CSRF 等前置处理耗时
• 用 time.perf_counter() 而非 time.time()，前者不受系统时间调整影响，更适合测量间隔
• 别直接 print，而应打到 logger，否则在异步视图或 Gunicorn 多 worker 下容易乱序或丢失
• 如果用了 django-debug-toolbar，它的 Timing panel 也显示总耗时，但它是基于中间件钩子计算的，和你手写的逻辑本质一致，只是 UI 更友好

简单中间件示意：

class RequestTimingMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response
def __call__(self, request):
    start = time.perf_counter()
    response = self.get_response(request)
    duration = time.perf_counter() - start
    logger.info(f"Request {request.path} took {duration:.3f}s")
    return response

为什么开了 SQL 日志却看不到 INSERT/UPDATE 参数值

这是常见错觉 —— 实际上 Django 默认就会展开参数，但前提是日志格式里包含 %(message)s，且后端驱动没做预编译隐藏。

• PostgreSQL（psycopg2）在 DEBUG 模式下会显示类似 INSERT INTO "user" ("name") VALUES (%s)，然后另起一行写 Args: ['Alice']；如果只看到占位符没看到 Args 行，说明日志 handler 没输出完整 record
• SQLite 不展开参数，只显示问号占位符，这是驱动限制，不是 Django 配置问题
• MySQL（mysqlclient）行为类似 PostgreSQL，但某些旧版本会把参数塞进 message 字段末尾，需检查日志格式是否截断了长消息
• 如果你用的是 django-sql-explorer 或其他查询工具，它们的日志是独立的，不影响 Django 原生日志行为

生产环境能不能开 SQL 日志？有没有性能代价

不能开，而且代价比想象中大 —— 不是“慢一点”，而是“请求延迟翻倍甚至更多”。

• 每条 SQL 查询都会触发一次完整的日志栈调用（包括 formatter、handler、I/O），在高并发下极易成为瓶颈
• 即使把日志级别设为 WARNING，只要 DEBUG=False，django.db.backends 根本不记录任何 SQL，配置再全也没用
• 真要排查线上慢查询，应该用数据库原生方案：pg_stat_statements（PostgreSQL）、慢查询日志（MySQL）、EXPLAIN ANALYZE 手动分析，而不是依赖 Django 日志
• 如果非要临时开启，务必限定 IP 或用户，且只开几分钟，结束后立刻关 —— 曾有项目因忘记关闭，导致 API 平均响应从 80ms 涨到 1.2s

复杂点在于：SQL 日志和请求耗时日志看似独立，但一旦同时开启，中间件计时会被日志 I/O 拖慢，导致“测出来慢，其实只是日志慢”。这点很容易被忽略。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~