需配置 logging 中 'django.db.backends' 的 level 为 debug 并指定 handlers；请求耗时用最前序中间件+time.perf_counter() 记录；sql 参数显示取决于驱动，sqlite 不展开；生产环境禁用 sql 日志以防性能陡降。
怎么让 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() 拿到毫秒级精度。重点不是“怎么写”，而是“在哪插、怎么避免干扰”。
立即学习“Python免费学习笔记（深入）”；
- 必须放在中间件列表最前面（即
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
<pre class='brush:python;toolbar:false;'>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 拖慢，导致“测出来慢，其实只是日志慢”。这点很容易被忽略。
