SaaS多租户场景下能否将动态指定的数据库作为数据集数据源？

完全支持动态指定数据库作为数据集数据源的诉求，且能完美匹配多独立同Schema库按权限加载、Dataset与具体库解耦的目标

核心实现思路 #

你面临的场景本质是多租户同Schema库的BI复用场景，不需要为每个客户单独建Dataset、配连接，只需要把原本绑定在Dataset上的「固定物理库连接」拆成两层：

• 保留通用层：所有Schema一致的业务查询逻辑（也就是Dataset本身的SQL、字段映射、图表配置）全部做成可复用的公共模板，不绑定任何具体客户的库
• 拆分变量层：把每个客户库独有的连接信息（库地址、库名、鉴权信息）作为可动态注入的参数，在数据查询触发时按当前登录用户的身份匹配填充

具体落地路径 #

1. 连接层动态路由（解耦效果最优） #

• 提前在平台侧维护一张租户连接映射表，字段至少包含：租户唯一标识、对应专属库的host地址、端口、库名、鉴权密钥
• 所有通用Dataset不再绑定具体客户的物理库连接，只统一绑定一个逻辑占位的「模板连接」
• 在Dataset发起数据库查询的统一拦截逻辑里，先提取当前登录用户绑定的租户ID，从映射表中取出对应库的连接参数，动态生成可用的数据库连接实例，替换掉模板连接的配置后再执行查询
• 这套逻辑落地后，新增客户只需要在映射表中补充一行连接配置，无需重复创建Dataset、配置图表，维护成本不会随客户数量线性上涨

2. SQL参数占位适配（适合平台能力有限的场景） #

• 如果所用BI平台暂不支持动态切换连接实例，可以直接在Dataset的SQL定义中预留库名占位符，比如把原写死的SQL select * from tenant_001.trade_order 修改为 select * from {{tenant_db}}.trade_order
• 在Dashboard加载阶段，由服务端根据当前登录用户的权限，匹配对应的租户库名传入占位符参数，拼接成最终可执行的SQL后，走公共的固定连接发起查询
• 注意这种方式下占位符的取值必须完全由服务端生成，绝对不能把参数修改权开放给前端，避免越权访问其他租户的数据

3. 必做的权限兜底校验 #

• 所有动态匹配库的逻辑必须在服务端完成校验，不能依赖前端传值：
  • 先校验当前登录用户是否有目标Dashboard的访问权限
  • 再校验用户所属租户ID与待查询库的映射关系是否合法
  • 禁止出现用户可自行修改库名参数的漏洞

常见避坑点 #

• 不要走「复制Dataset模板给每个客户单独绑库」的弯路，这种方式会导致后续改一个字段就要同步改几十上百份Dataset，完全失去解耦的意义
• 动态生成的数据库连接要做好连接池隔离，避免单个租户的慢查询、查询异常影响其他租户的数据加载稳定性
• 租户连接映射表要做本地缓存，不要每次查询都实时查表，避免增加不必要的接口开销

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