基于单库多Schema多租户的纯隔离数据库连接优化方案咨询

现有方案的改进思路 #

方案一（请求级创建连接）的优化 #

• 引入连接池复用机制：不为每个请求新建连接，而是给每个租户用户维护一个小型连接池。初始化时预创建少量连接，请求到来时从对应租户的连接池取空闲连接，请求结束后归还。既保证租户隔离，又避免频繁创建连接的开销。
• 连接池动态伸缩：根据租户请求量调整连接池大小，低活跃租户自动收缩连接数，减少资源浪费。

方案二（内存映射复用数据源）的优化 #

• 实现数据源懒加载与过期回收：仅当租户有请求时才创建对应数据源，同时设置闲置超时时间，超过时限无请求的租户数据源自动销毁释放内存。
• 共享基础配置：不同租户的数据源共享驱动类、数据库地址等基础配置，仅差异化存储租户专属的用户名、密码、Schema配置，减少内存重复占用。

更优的替代方案 #

基于连接池的租户隔离策略 #

自定义扩展支持租户隔离的连接池（如HikariCP），核心逻辑：

1. 为每个租户用户配置独立的连接池参数（初始连接数、最大连接数等）。
2. 维护租户标识到连接池的映射表，首次请求时初始化对应租户的连接池，后续请求直接复用。
3. 结合连接池监控与自动清理：定期检查连接池活跃状态，销毁长期无请求的租户连接池，释放内存。

数据库权限强化+连接复用 #

1. 保留第一阶段search_path切换逻辑，但将超级用户替换为仅拥有Schema切换权限的中间用户：该用户无任何Schema的读写权限，仅能执行SET search_path命令，再通过SET ROLE切换到租户专属用户执行SQL。
2. 复用单一连接池：所有请求先获取中间用户的连接，切换search_path后再切换到租户角色，执行完SQL后还原角色。既实现权限隔离，又避免多租户连接池的内存压力。
   示例伪代码：

Connection getConnection(String tenantIdentifier) {
    Connection conn = sharedConnectionPool.getConnection();
    // 切换到租户Schema
    conn.execute("SET search_path TO \"" + tenantIdentifier + "\"");
    // 切换到租户专属角色
    conn.execute("SET ROLE " + getTenantRole(tenantIdentifier));
    return conn;
}

// 请求结束后清理
void releaseConnection(Connection conn) {
    conn.execute("RESET ROLE");
    conn.execute("RESET search_path");
    sharedConnectionPool.releaseConnection(conn);
}

• 优势：既保证租户权限隔离（租户角色仅能访问自身Schema），又复用单一连接池，无频繁创建连接的开销，也避免多连接池的内存占用问题。

注意事项 #

• 严格校验租户标识，防止SQL注入（对tenantIdentifier转义或使用预编译语句执行SET search_path）。
• 监控各租户连接使用情况，避免个别租户占用过多资源影响其他租户。

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