PostgreSQL多租户需为每个租户创建独立schema并动态设置search_path，避免连接复用导致上下文残留；Django推荐django-tenants，SQLAlchemy宜用engine.connect事件设schema；pg_dump必须显式指定-n备份非public schema。
PostgreSQL 中如何为每个租户创建独立 schema
多租户用 schema 隔离，本质是把 public 换成动态的 tenant_123，但 PostgreSQL 不允许在普通 SQL 里拼接 schema 名——SELECT * FROM {tenant_schema}.users 会报错。必须用动态 SQL 或连接层控制。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 租户注册时，用超级用户或专用管理连接执行
CREATE SCHEMA IF NOT EXISTS tenant_abc，再运行预置的 DDL 脚本（建表、索引、约束） - 应用连接数据库时，**不复用连接池中的连接**，而是在获取连接后立即执行
SET search_path TO tenant_abc；否则连接被复用时可能残留上一个租户的 schema 上下文 - 避免在 migration 工具（如 Alembic）中直接操作多 schema——它默认只管
public，需手动扩展target_metadata或拆分 migration 路径 - 注意
pg_dump默认不导出非publicschema，备份租户需显式指定-n tenant_xyz
Django 如何在请求生命周期中自动切换 schema
Django 本身不支持多 schema，靠中间件 + 自定义数据库路由勉强实现，但容易漏掉 ORM 初始化、信号、admin 等隐式路径。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 用
django-tenants是最省事的选择，但它强制要求所有模型继承TenantMixin，且publicschema 必须存在并存放共享表（如auth_user），不能全租户隔离 - 若坚持手写，关键点在：在中间件
process_request中解析子域名或 header（如X-Tenant-ID），然后调用connection.cursor().execute("SET search_path TO ...")；**必须在任何 ORM 查询前完成**，否则User.objects.all()还是查public - Admin 后台默认不走中间件的 schema 设置，需重写
get_queryset并手动加using或 patchconnection - 注意 Celery 任务脱离 HTTP 请求上下文，必须显式传入
tenant_id，并在任务开头重新 set search_path
SQLAlchemy 怎么让 session 绑定到当前租户 schema
SQLAlchemy 的 Engine 是全局的，但 Connection 和 Session 可以绑定不同 schema。难点在于如何让每次请求的 session 自动带上正确的 search_path，而不是靠开发者每次手动写 session.execute("SET search_path TO ...")。
图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 不要改
create_engine的 URL（比如加?options=-c%20search_path%3Dtenant_abc），这会让所有连接固定在一个 schema，无法动态切换 - 推荐用事件钩子：监听
engine.connect事件，在返回 connection 前执行conn.execute("SET search_path TO :schema", {"schema": current_tenant}) - 如果用 FastAPI，可在依赖函数中创建
SessionLocal实例，并在__init__里注入 schema；但要注意 Session 构造时不触发连接，真正执行查询时才连，所以仍需配合 connect 事件 - 警惕
session.execute(text("SELECT ..."))：如果 SQL 字符串里没带 schema 前缀（如tenant_abc.users），又没提前 set search_path，就会查错表
为什么 pg_dump / restore 容易搞丢租户数据
因为 pg_dump 默认只 dump public schema，即使你有 50 个 tenant_* schema，不加参数就全丢了。更隐蔽的是，restore 时如果目标库已存在同名 schema，pg_restore 默认跳过建 schema 步骤，导致表被创建到 public 下。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 备份单租户：用
pg_dump -n tenant_abc -Fc mydb > tenant_abc.dump；-n必须指定，-Fc保证可选择性 restore - 恢复前先清理：用
psql -c "DROP SCHEMA IF EXISTS tenant_abc CASCADE"，否则pg_restore -n tenant_abc可能报 “schema already exists” 并静默失败 - 别信
pg_dump --inserts：它生成 INSERT 语句但不带 schema 前缀，restore 到非publicschema 时会失败；应保持默认的 COPY 方式 - 自动化脚本里记得检查
pg_dump返回码，有时它对不存在的 schema 只 warn 不 error，脚本却以为成功了
schema 隔离看着干净，但所有数据库交互点都得显式兜住租户上下文——ORM 查询、raw SQL、migration、backup、job、admin、甚至数据库连接池回收逻辑。少一个环节，数据就跨租户了。
