PowerShell传参调用SQL时如何实现SQL嵌套调用且不使用xp_cmdshell

你当前碰到的核心问题本质是：SQL Server引擎本身没有提供低权限的外部SQL文件原生调用能力，只要把跨文件调用的逻辑从SQL侧迁移到外层PowerShell侧，或是把依赖的支撑SQL逻辑收敛到当前会话上下文，就能完全绕开xp_cmdshell权限、数据库永久对象新增这两个你明确要规避的问题，不需要把所有SQL逻辑重写为PowerShell实现。

• 方案1：调用逻辑全收口到PowerShell，零数据库侧改动
  完全移除主SQL文件里所有调用外部文件、启动外部进程的逻辑，把所有SQL文件的加载、参数替换、执行顺序管控全部放到PowerShell层实现：

  1. PowerShell脚本按执行顺序，读取主SQL、所有支撑SQL文件的纯文本内容
  2. 统一在PowerShell侧完成所有SQL文本内的参数占位符替换（可以直接沿用Invoke-Sqlcmd原生支持的$(变量名)占位符格式，不需要自己额外写替换逻辑）
  3. 识别SQL文本里的GO批处理分隔符，按顺序分段通过Invoke-Sqlcmd传入对应参数执行即可
     整个流程完全不需要开启xp_cmdshell，不需要配置任何代理账户，也不需要在客户数据库里创建任何对象，部署时只需要把所有SQL文件和PowerShell脚本按原有目录结构放好就能跑。

• 方案2：会话级临时存储过程方案，改造成本最低
  如果你不想调整现有PowerShell侧的调用逻辑，也不需要创建永久存储过程：
  直接把所有支撑SQL文件的逻辑，封装为以#开头的临时存储过程，写到主SQL文件的最开头。这类临时存储过程仅在当前数据库连接的会话生命周期内有效，连接断开后会被数据库自动清理，完全不会在客户数据库中残留任何永久对象。
  改造时只需要把原来主SQL里调用外部支撑SQL的位置，替换为对应临时存储过程的传参调用即可，参数传递用存储过程原生入参实现，不存在OPENROWSET读纯文本无法替换参数的问题，整个主SQL仍然是单文件，PowerShell只需要像之前一样调用单个主SQL文件传参就能正常运行。

• 不推荐的方向说明
  不建议继续尝试在SQL侧通过OPENROWSET、sp_executesql加载外部SQL文件的方案：这类操作默认需要开启服务器级的Ad Hoc Distributed Queries权限，安全风险比配置xp_cmdshell代理账户更高，客户侧的接受度会更低，部署排查成本也更高。

整体来看你最初的优化方向没有问题，只是把跨文件调用的执行主体放错在了SQL引擎层，调整后整个链路的落地复杂度远低于把所有SQL逻辑改写为PowerShell实现，也不会给客户侧增加额外的部署配置负担。

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