xp_cmdshell默认禁用，启用需先开启show advanced options，再配置xp_cmdshell为1，且全程须由sysadmin执行；禁用顺序相反，普通账号不可操作，调用时应避免拼接用户输入以防命令注入。

xp_cmdshell 默认被禁用，直接调用会报错 SQL Server blocked access to procedure 'sys.xp_cmdshell'。必须先启用它，且需 sysadmin 权限——普通应用账号不应拥有该权限。

启用 xp_cmdshell 的最小权限操作

SQL Server 出于安全考虑，默认关闭 xp_cmdshell。启用不是简单执行一句 sp_configure 'xp_cmdshell', 1 就完事，它依赖外围配置开关：

• 先执行 sp_configure 'show advanced options', 1，再 RECONFIGURE
• 再执行 sp_configure 'xp_cmdshell', 1，再 RECONFIGURE
• 禁用时按相反顺序：先关 xp_cmdshell，再关 show advanced options
• 整个过程必须由 sysadmin 角色用户执行；非 sa 账号即使被显式授予权限也无法启用

在存储过程中安全调用 xp_cmdshell

即便启用了 xp_cmdshell，也不建议在业务存储过程中硬编码命令。常见错误是拼接用户输入导致命令注入，比如：

DECLARE @cmd NVARCHAR(4000) = 'dir ' + @user_input;
EXEC master..xp_cmdshell @cmd;

正确做法是严格过滤、白名单校验或使用参数化外壳（如通过 PowerShell 脚本封装）：

• 避免直接拼接 @user_input，改用 QUOTENAME() 或正则预检（如只允许字母、数字、下划线）
• 命令路径尽量写绝对路径，避免环境变量污染，例如用 C:\Windows\System32\ping.exe 而非 ping
• 捕获输出需借助临时表：CREATE TABLE #cmdout (line NVARCHAR(4000)); INSERT INTO #cmdout EXEC xp_cmdshell 'whoami'
• 注意返回值：xp_cmdshell 成功返回 0，失败通常为非 0（但不保证一致），不能仅靠 NULL 判断失败

替代方案：为什么应该避免 xp_cmdshell

启用 xp_cmdshell 相当于给数据库进程开了一个本地 shell 入口，一旦 SQL 注入或账号泄露，攻击者可直接提权到操作系统层。生产环境更稳妥的做法包括：

• 用 SQL Server Agent 作业调度外部程序，由 Windows 服务账户隔离执行上下文
• 通过 CLR 集成编写受控的 .NET 方法（需 UNSAFE ASSEMBLY，同样高风险，但可精细控制权限）
• 将需执行的操作下沉到应用层：数据库只负责数据，命令行交由后端服务调用并审计
• 若仅为日志或备份触发，优先使用内置命令如 BACKUP DATABASE 或 sp_whoisactive 等替代

真正难的不是怎么让 xp_cmdshell 跑起来，而是确认“非它不可”——多数场景其实有更收敛、可审计、权限更低的路径。哪怕只是临时调试，也别在生产实例上长期开着它。