新建数据库还是复用现有库？跨库查询存储过程部署方案咨询

这个问题在做跨库检索类应用时挺常见的，得从运维成本、权限安全、维护复杂度这几个核心点来权衡，我给你拆解下两种方案的利弊，再结合你的场景给点建议：

优点 #

• 不用额外折腾新数据库实例，省了运维和资源开销，尤其是如果所有库都在同一个数据库集群里的话
• 跨库访问的权限配置相对简单，毕竟存储过程所在的库本来就和其他被查库在同一个环境里（如果之前已经有跨库权限基础的话）
• 数据访问延迟可能更低，避免跨实例的额外网络损耗

缺点 #

• 会打乱原有数据库的命名空间，新增的存储过程/视图很容易和原有业务对象重名，后期维护的时候容易搞混，分不清哪些是原有业务的，哪些是跨库检索用的
• 原有数据库的结构变更、版本升级可能会牵连到这些跨库对象，反过来，你修改这些检索逻辑的时候也可能影响原有业务的正常运行
• 权限管理容易出问题：如果不同被查库属于不同业务线，给新应用授权时可能不得不开放原有业务库的额外权限，存在数据泄露的风险

优点 #

• 关注点彻底分离：原有业务库专心处理自身核心业务，中间库专门负责跨库检索逻辑，边界清晰，后续排查问题、维护起来都省心很多
• 权限管控更安全：只需要给中间库配置访问各个被查库的必要权限，新应用只需要对接中间库就行，不用直接接触业务库的核心数据，降低了安全风险
• 统一管理更方便：所有跨库查询逻辑都放在一处，修改、调试、监控都集中进行，后续要新增查询库或者优化性能也更顺手
• 隔离性强：原有业务库的任何变更都不会直接影响检索逻辑，中间库的调整也不会干扰业务库的正常运行

缺点 #

• 多了一个数据库实例（如果单独部署的话），会增加一点点运维成本和资源占用，但对于你只有十余条存储过程/视图的场景，这个开销几乎可以忽略
• 如果是跨实例访问的话，可能会有轻微的网络延迟，但对于历史数据检索这类非实时性要求极高的场景，完全不影响使用

结合你的情况：多个独立数据库、十余条跨库检索对象、新应用是做历史数据查询，我更推荐新建专属中间数据库的方案，原因如下：

1. 你的需求是跨多个独立库的检索，中间库能把这些分散的逻辑收拢在一起，后续要是新增需要查询的数据库，扩展起来也更方便
2. 历史数据检索属于非核心业务，和原有业务分离开来，不会给原有业务库带来额外的稳定性风险
3. 多库场景下，权限和维护的优势会更突出，避免给原本独立的业务库引入不必要的复杂度

如果实在不想新增数据库，退一步的话，可以选一个业务相对不活跃、和其他库关联性弱的现有库来部署这些跨库对象，但一定要严格做好命名规范（比如给所有跨库对象加统一前缀CrossDB_），避免和原有对象冲突，同时要最小化权限配置，只开放必要的访问权限。

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