1. 独立 Schema 的适用场景当你有几十到几百个中大型租户既想要强隔离、又不想维护几百个数据库实例时独立 Schema 是甜点方案同一 PostgreSQL 实例内kb_a.doc、kb_b.doc互相不可见DDL 变更比独立库轻拓扑见图 figure_05_1。知识库场景下每个租户的文档表、chunk 表、向量表各占一个 Schema索引互相独立、互不影响。2. 动态数据源路由设计核心思路一个逻辑数据源背后挂 N 个物理数据源或同一库 N 个 Schema运行时按tenantId决定路由到哪个设计见图 figure_05_2。Spring 的AbstractRoutingDataSource正好干这个——determineCurrentLookupKey()返回租户标识框架据此选数据源。3. Schema 初始化与 Flyway 多租户新租户入驻要自动建 Schema 并跑迁移脚本。Flyway 本身不带多租户需要循环每个 Schema 执行publicvoidinitTenantSchema(StringtenantId){Stringschemakb_tenantId;jdbcTemplate.execute(CREATE SCHEMA IF NOT EXISTS schema);FlywayflywayFlyway.configure().dataSource(dataSource).schemas(schema).locations(db/tenant).load();flyway.migrate();// 在该 Schema 内建表/建向量索引}4. AbstractRoutingDataSource 落地BeanpublicDataSourcedataSource(DataSourceRegistryregistry){AbstractRoutingDataSourcedsnewAbstractRoutingDataSource(){OverrideprotectedObjectdetermineCurrentLookupKey(){returnTenantContext.get();// tenant-a / tenant-b}};ds.setTargetDataSources(registry.all());// MaptenantId, DataSourceds.setDefaultTargetDataSource(registry.defaultDs());returnds;}// 每个物理库用 search_path 指向 kb_tenant 的 Schema关注点做法路由键TenantContext.get()Schema 切换SET search_path kb_tenant连接池每物理库独立池避免某租户拖垮全局新建租户动态注册数据源 初始化 Schema5. 运维注意点连接池隔离每个物理数据源独立池防止大租户占满连接拖垮其他租户。DDL 批量Schema 多了升级脚本要一次性批量跑完做好失败回滚。备份粒度可按 Schema 单独备份恢复单租户更快。search_path 注入kb_tenant同样要白名单校验避免kb_a; DROP之类。6. 小结独立 Schema 用动态数据源 按租户路由在隔离与成本间取得平衡是多租户知识库的常见落地形态。下一篇进入向量库本身的隔离——这是大模型场景最特殊、最容易踩坑的一层。