SQL Server存储过程中USE无法切换数据库上下文，因对象名在编译时已绑定到存储过程所在库；跨库访问必须使用三段式名称（[DB].[Schema].[Obj]），动态SQL需QUOTENAME()转义并校验数据库存在性与权限。
不能在存储过程中用 USE 切换数据库上下文来执行后续静态 SQL —— 这是 SQL Server 的硬限制，USE 只影响当前批处理（batch）的上下文，而存储过程体是一个独立作用域，USE 的效果不会延续到后面的语句中。
为什么 USE 在存储过程中“不生效”
SQL Server 解析存储过程时会预先绑定对象名（如 SELECT * FROM Users 中的 Users），此时默认使用存储过程所在数据库。即使你在过程里写 USE OtherDB; SELECT * FROM Table1;，第二条语句仍会在原数据库中查找 Table1，报错 Invalid object name 'Table1'。根本原因是 USE 不改变已编译语句的解析上下文。
常见错误现象：
- 执行后无报错但结果来自错误数据库
Msg 208, Level 16, State 1: Invalid object name 'xxx'- 动态拼接了库名但忘了加括号或转义，导致 SQL 注入或语法错误
正确做法：所有跨库访问必须显式带三段式名称
即 [DatabaseName].[SchemaName].[ObjectName]。这是唯一被 SQL Server 静态解析器支持的跨库引用方式。动态切换的本质，是把数据库名作为变量拼进这个三段式结构里，再交给 sp_executesql 执行。
实操建议：
- 始终用方括号包裹数据库名变量，防止含特殊字符或关键字（如
[My-DB]、[order]）出错 - 用
QUOTENAME()安全转义，比如QUOTENAME(@db_name)，别直接拼字符串 - 避免用
EXEC(@sql)，优先用sp_executesql支持参数化，防注入且可复用执行计划 - 如果要查多个对象，每个对象前缀都要补全，不能只写一次库名就以为全局生效
示例：
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;
如何安全校验传入的数据库名
用户传参不可信，直接拼接 @db_name 可能引发注入（比如传入 N'] ; DROP DATABASE master; --）。必须先验证该数据库真实存在且调用者有权限。
实操建议：
- 查系统视图
sys.databases确认数据库状态为ONLINE且state = 0 - 用
HAS_DBACCESS()检查当前登录是否有访问权限，返回 1 才继续 - 拒绝空值、NULL、仅空白符、含反斜杠或控制字符的输入
- 若业务允许，把合法库名限定在白名单表里（如
Config.AvailableDatabases），而非依赖系统视图
校验片段示例：
IF NOT EXISTS (SELECT 1 FROM sys.databases WHERE name = @db_name AND state = 0)
THROW 50000, 'Database does not exist or is offline.', 1;
IF HAS_DBACCESS(@db_name) <> 1
THROW 50000, 'No access to specified database.', 1;性能与维护注意事项
动态 SQL 无法享受查询计划缓存优势（尤其参数变化频繁时），而且三段式名称会让执行计划无法跨库复用。更隐蔽的问题是权限模型：调用者需对目标库中涉及的所有对象有显式权限，不能靠 db_owner 角色隐式继承（因为跨库后角色不传递）。
容易被忽略的地方：
- 目标库中表的架构名（
schema）不能省略，dbo不是默认值——如果表在sales架构下，必须写[OtherDB].sales.Table1 - 链接服务器场景下，四段式名称（
[Server].[DB].[Schema].[Obj]）同样适用，但网络延迟和分布式事务开销要提前评估 - 日志和监控工具可能无法捕获动态 SQL 中的真实库名，排查时得从
sys.dm_exec_query_stats或 Extended Events 抓原始语句
