SQL Server存储过程中USE无效，因解析时对象已绑定原库；必须用三段式名称+sp_executesql动态执行，且数据库名需QUOTENAME转义并校验权限与存在性。
不能在存储过程中用 USE 切换数据库上下文来影响后续静态 SQL 的执行 —— 这是 SQL Server 的硬限制，不是写法问题，而是解析机制决定的。
为什么 USE 在存储过程里“不生效”
SQL Server 编译存储过程时，所有对象名（如 SELECT * FROM Users 中的 Users）已绑定到过程所在数据库。即使你写 USE OtherDB; SELECT * FROM Table1;，第二句仍会在原库中找 Table1，报错 Msg 208, Level 16, State 1: Invalid object name 'Table1'。
根本原因是：USE 只作用于当前批处理（batch），而整个存储过程体是一个独立编译单元，USE 的效果不会延续到后续语句。
- 常见错误现象：执行无报错但结果来自错误数据库
- 动态拼接了库名但没加方括号，遇到
My-DB或order这类名字直接语法失败 - 直接拼接用户输入的
@db_name，没校验，导致 SQL 注入（比如传入N'] ; DROP DATABASE master; --）
正确做法：用三段式名称 + sp_executesql
跨库访问唯一被静态解析器支持的方式，是显式写出 [DatabaseName].[SchemaName].[ObjectName]。动态切换的本质，就是把数据库名变量安全拼进这个结构里，再交给 sp_executesql 执行。
- 必须用
QUOTENAME(@db_name)转义，不能直接拼' + @db_name + ' - 优先用
sp_executesql，不是EXEC(@sql)：前者支持参数化、防注入、可复用执行计划 - 每个跨库对象都得补全前缀，不能只写一次库名就以为“全局生效”
- 示例：
DECLARE @db_name NVARCHAR(128) = N'AdventureWorks'; DECLARE @sql NVARCHAR(MAX); SET @sql = N'SELECT TOP 5 * FROM ' + QUOTENAME(@db_name) + N'.dbo.Person;'; EXEC sp_executesql @sql;
如何安全校验传入的数据库名
用户传参不可信，必须在拼 SQL 前确认该库真实存在、状态正常、且调用者有权限。
- 查
sys.databases确认state = 0（ONLINE）且未被排除 - 用
HAS_DBACCESS(@db_name)检查权限，返回1才继续 - 拒绝空值、仅空白符、含反斜杠或控制字符的输入
- 业务允许时，建议白名单控制：从配置表（如
Config.AvailableDatabases）查合法库名，而非依赖系统视图
别踩 EXECUTE AS 的坑：它不解决跨库问题，但能管住权限边界
EXECUTE AS OWNER 或 EXECUTE AS 'username' 是为权限隔离设计的，不是为切换数据库上下文。它不影响对象名解析逻辑，只是让后续语句（包括动态 SQL）以指定身份运行。
- 如果你在过程里用
EXECUTE AS OWNER，然后拼[OtherDB]...，那没问题；但如果忘了加库名前缀，还是会去原库找表 - 所有权链（ownership chaining）只在同 owner 的对象间生效；跨库必然中断，所以不能靠它省略三段式
- 动态 SQL 在
EXECUTE AS CALLER下完全继承调用者权限，极易被注入利用；换成OWNER后，哪怕拼了恶意库名，只要该用户没权限访问，也会被拦在门口
真正容易被忽略的是：三段式不是“可选优化”，而是 SQL Server 静态解析的强制要求；任何试图绕过它的方案（比如封装 USE 存储过程、用 SET DEFAULT_DATABASE）在存储过程体内都无效。安全性和正确性，必须从第一行拼接开始控制。
