Django多租户设置CONN_MAX_AGE是否会引发Schema连接池混用问题？

核心结论 #

默认情况下，Django的连接池会将使用同一数据库配置（即default）的连接归为同一池，不会区分PostgreSQL搜索路径（Schema）的差异。这意味着不同租户的连接可能被混存复用，新请求拿到的连接可能残留着其他租户的Schema设置，引发数据访问错误。

针对你的担忧逐一说明 #

1. 所有用户共用default数据库，仅搜索路径不同 #

这正是问题的核心。Django连接池的划分依据是数据库配置名称，而非会话级的搜索路径设置。所以即便不同租户的Schema不同，只要用的是同一个default数据库配置，连接就会被放进同一个池子里。

2. 无连接绑定到用户会话的逻辑 #

Django本身没有将连接与用户会话绑定的机制。连接池是按线程/进程（取决于服务器类型）管理的：比如Gunicorn多进程环境下，每个进程有独立的连接池，连接仅在该进程内的请求间复用；同一进程内的不同租户请求，完全可能复用同一个带有旧Schema设置的连接。

3. 内置开发服务器忽略CONN_MAX_AGE #

确实如此，runserver在开发模式下会在每个请求结束后强制关闭连接，无法测试连接持久化场景。你可以用Gunicorn、uWSGI这类生产级服务器做本地测试，不建议修改runserver的默认行为，容易引发其他问题。

4. connection_created信号的使用风险 #

直接使用该信号大概率会和django-tenants的中间件逻辑冲突——django-tenants正是通过中间件设置租户Schema的。如果信号里重复设置，可能出现时序问题（比如中间件刚设置好，信号又覆盖），或者连接复用时无法重置到当前租户的Schema，引发未知错误。

可行解决方案 #

1. 依赖django-tenants的原生适配
   确保你使用的django-tenants版本兼容Django 4.0.7，它已经针对连接池场景做了处理：在连接复用前会自动将搜索路径重置为当前租户的Schema，无需额外配置。

2. 自定义中间件校验Schema
   在django-tenants中间件之后添加自定义中间件，每次请求开始时校验当前连接的Schema是否匹配租户，不匹配则重新设置：

   from django.db import connection
   from django_tenants.utils import get_tenant_model
   
   class TenantSchemaVerifyMiddleware:
       def __init__(self, get_response):
           self.get_response = get_response
   
       def __call__(self, request):
           Tenant = get_tenant_model()
           tenant = getattr(request, 'tenant', None)
           if tenant:
               with connection.cursor() as cursor:
                   cursor.execute("SHOW search_path")
                   current_schema = cursor.fetchone()[0]
                   if current_schema != tenant.schema_name:
                       cursor.execute(f"SET search_path TO {tenant.schema_name}, public")
           response = self.get_response(request)
           return response
   

3. 合理设置CONN_MAX_AGE时长
   如果担心上述方案有遗漏，可以将CONN_MAX_AGE设为较短时长（比如30秒），既降低连接创建/销毁的负载，又减少连接被不同租户复用的概率。

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