sql server存储过程无法通过配置表自动跳转逻辑分支，因执行路径在编译时已固定；动态切换必须用sp_executesql拼接完整sql字符串，结构部分（如表名）用quotename()转义，值部分参数化传递，并提前校验数据库状态、权限及白名单。
存储过程里不能靠配置表“自动跳逻辑分支”
SQL Server 存储过程在编译时就确定执行路径，IF、CASE 等控制语句的条件判断只作用于运行时值，但整个过程体是静态解析的。你不能指望“查一次配置表 → 改变后续 SQL 的语法结构或对象绑定”，比如让 SELECT * FROM @table_name 在不拼字符串的情况下生效——这会直接报错 Must declare the scalar variable "@table_name"。
常见错误现象：
- 把配置表查出来的值（如
@logic_type = 'v2'）直接用于FROM或ALTER TABLE后面，期望自动切换表或行为 - 用
EXEC('...')拼接整段逻辑，但没做QUOTENAME()转义，遇到库名含-或order就失败 - 配置表字段类型为
VARCHAR，但传给sp_executesql时没转成NVARCHAR(MAX)，导致中文乱码或截断
必须用动态 SQL 显式拼接不同分支的完整语句
真正的“动态切换”不是改流程，而是根据配置查出参数后，生成并执行完全不同的 SQL 字符串。核心是：结构部分（表名、列名、库名）拼进字符串；值部分（WHERE 条件里的 ID、日期）走 sp_executesql 参数化。
实操建议：
- 先
SELECT @logic_type = logic_code FROM Config.LogicRules WHERE rule_id = @rule_id查配置 - 用
CASE @logic_type WHEN 'A' THEN N'SELECT ... FROM [DB_A]...' WHEN 'B' THEN N'SELECT ... FROM [DB_B]...'构建@sql - 所有数据库名、模式名、表名都套
QUOTENAME(@db_name)，哪怕你确信它安全 - 如果分支涉及 DDL（如新增列），必须单独写
ALTER TABLE动态块，且加IF NOT EXISTS (SELECT 1 FROM sys.columns...)防重复
配置表字段设计要匹配 SQL 安全要求
配置表不是随便存个字符串就行。字段类型、长度、校验规则直接影响动态 SQL 是否能安全执行。
关键点：
-
db_name字段必须是SYSNAME或NVARCHAR(128)，不能是VARCHAR(500)—— 过长可能被截断，过短则存不下带实例名的库（如[MyServer\Instance].db） -
sql_template字段若存在，内容必须已预审：不含GO、不含未转义的单引号、不含;分隔多条语句（除非你明确用EXEC(@sql)且接受批处理风险） - 加一列
is_enabled BIT DEFAULT 1，避免停用规则仍被读取执行 - 业务上允许的话，把合法值限定在白名单视图里，比如
SELECT db_name FROM Config.AllowedDatabases WHERE is_active = 1，而不是直接拼用户输入
最易被忽略的执行上下文陷阱
即使你拼对了 SQL、转义了名字、参数也传对了，sp_executesql 执行时仍可能失败——因为它的执行上下文默认是存储过程所在数据库，而你拼的三段式名称（如 [OtherDB].[dbo].[Orders]）虽然语法正确，但如果 OtherDB 处于 OFFLINE 状态，或当前登录没有 SELECT 权限，就会卡在运行时报错，不是编译期。
所以务必在拼 SQL 前检查：
-
SELECT state_desc FROM sys.databases WHERE name = @db_name AND state = 0（确认 ONLINE） -
SELECT HAS_DBACCESS(@db_name)返回 1 才继续 - 如果涉及跨库 JOIN，注意统计信息不会跨库自动更新，可能导致执行计划劣化——这不是代码问题，但线上容易突然变慢
真正麻烦的从来不是“怎么拼”，而是“拼完之后谁来担保它在每个环境都跑得通”。配置表只是开关，背后每个分支对应的 SQL、权限、数据状态，都得单独验证。
