SQL Server存储过程无法动态拼接列名，因列名须编译期确定；必须用动态SQL（配合QUOTENAME和白名单）或LEFT JOIN+COALESCE方案替代。
直接说结论：SQL Server 存储过程中无法“动态拼接列名”执行查询，SELECT @lang_col FROM ... 会报错，必须用动态 SQL 或预定义视图/CTE。
为什么不能直接用变量当列名
SQL Server 解析器在编译阶段就要求所有列名可静态识别。像 @lang_col 这种变量，在 SELECT 子句中会被当作普通标量值或未声明变量处理，而不是列标识符。常见错误是：
Invalid column name '@lang_col' 或 Must declare the scalar variable "@lang_col"
这不是权限或语法写错的问题，是 T-SQL 语言设计限制 —— 列名必须在编译期确定。
安全可行的替代方案：动态 SQL + 参数化拼接
核心思路是：把语言列名（如 name_zh、name_en）作为输入参数传入，用 QUOTENAME() 防注入，再拼进 EXEC sp_executesql 中执行。
示例存储过程片段：
CREATE PROCEDURE usp_GetProductByLang
@LangCode VARCHAR(5) = 'zh'
AS
BEGIN
DECLARE @sql NVARCHAR(MAX);
DECLARE @col_name SYSNAME;
<pre class='brush:php;toolbar:false;'>-- 映射语言代码到实际列名（避免用户传任意字符串）
SELECT @col_name = CASE @LangCode
WHEN 'zh' THEN 'name_zh'
WHEN 'en' THEN 'name_en'
WHEN 'ja' THEN 'name_ja'
ELSE 'name_zh'
END;
SET @sql = N'SELECT product_id, ' + QUOTENAME(@col_name) + N', price FROM products';
EXEC sp_executesql @sql;END;
关键点：
-
QUOTENAME()必须包裹列名，防止 SQL 注入（比如传入zh'; DROP TABLE products--） - 不建议让用户直接传列名，应做白名单映射（如上
CASE） - 动态 SQL 无法被缓存重用（每次执行都需重新编译），高并发下注意性能
更稳定的选择：用 LEFT JOIN + COALESCE 拆成多语言子表
如果多语言数据已按规范存在独立子表（如 products_Trl），推荐用 LEFT JOIN + COALESCE，完全规避动态 SQL：
假设主表 products 有 product_id，子表 products_Trl 有 product_id、lang_code、name 三列：
CREATE PROCEDURE usp_GetProductByLangJoin
@LangCode VARCHAR(5) = 'zh'
AS
BEGIN
SELECT
p.product_id,
COALESCE(t.name, p.name_fallback) AS name,
p.price
FROM products p
LEFT JOIN products_Trl t
ON p.product_id = t.product_id AND t.lang_code = @LangCode;
END;优势：
- 无需动态 SQL，执行计划稳定，可复用
- 自动 fallback：查不到指定语言时返回主表默认值（
name_fallback） - 索引友好：
(product_id, lang_code)复合索引能高效命中 - 符合 SQL Server 多语言建模惯例（如 U9 的
_Trl表模式）
容易忽略的坑：排序与 WHERE 条件中的语言列
如果查询需要按语言字段排序或过滤（比如 WHERE name_en LIKE '%abc%'），动态 SQL 是唯一选择 —— COALESCE 只适用于 SELECT 投影，不能用于 WHERE 或 ORDER BY 的表达式中（除非用 OPTION (RECOMPILE) 强制重编译，但代价高）。
此时必须确保：
- 所有语言列都有独立索引（如
IX_products_Trl_lang_code_name） - 避免在动态 SQL 中拼接用户输入的
WHERE条件，改用sp_executesql的参数占位符 - 测试
@LangCode为空或非法值时的行为，防止空结果集静默失败
最麻烦的不是写法，而是后续维护者是否意识到：这个存储过程的执行计划和索引策略，完全取决于运行时传入的语言参数 —— 它不是“一个查询”，而是一组逻辑等价但物理执行路径不同的查询。
