SQL Server存储过程中不能直接用变量作列名，因T-SQL编译期不识别运行时变量；须用QUOTENAME()+sp_executesql动态执行，或改用LEFT JOIN+COALESCE()关联翻译表，并确保字段为NVARCHAR及正确COLLATE。
SQL Server 存储过程中不能直接用变量当列名，SELECT @lang_col FROM products 必然报错 —— 这不是写法问题，是 T-SQL 编译期限制决定的。
为什么 SELECT @col 会报 “Invalid column name”
SQL Server 在编译阶段就解析列名，@lang_col 是运行时变量，解析器既不把它当标识符，也不当作已声明标量（除非你真在前面 DECLARE @lang_col VARCHAR(10)，但那只会返回字符串字面值）。典型错误信息是：Invalid column name '@lang_col' 或 Must declare the scalar variable "@lang_col"。这不是权限、拼写或连接问题，是语言机制本身不允许。
用 QUOTENAME() + sp_executesql 安全拼接列名
必须走动态 SQL，但绝不能直接拼接用户输入。关键三步：白名单映射 → QUOTENAME() 包裹 → sp_executesql 执行。
示例中只允许 'zh'、'en'、'ja' 三种语言代码，对应固定列名：
DECLARE @col_name SYSNAME; SELECT @col_name = CASE @LangCode WHEN 'zh' THEN 'name_zh' WHEN 'en' THEN 'name_en' WHEN 'ja' THEN 'name_ja' ELSE 'name_zh' END; DECLARE @sql NVARCHAR(MAX) = N'SELECT product_id, ' + QUOTENAME(@col_name) + N', price FROM products'; EXEC sp_executesql @sql;
-
QUOTENAME(@col_name)防止注入（比如传入zh'; DROP TABLE products--会被转成[zh'; DROP TABLE products--]，变成非法标识符而报错，不执行） - 不用
EXEC(@sql)，必须用sp_executesql—— 后者支持参数化（虽然本例没传参数，但为后续扩展留余地） - 每次执行都重新编译，高并发下可能影响性能；若查询极频繁，考虑缓存结果或改用 JOIN 方案
用 LEFT JOIN + COALESCE() 规避动态 SQL
如果多语言数据已存在独立翻译表（如 products_Trl），这是更稳定、可索引、易维护的选择。
假设结构为：products(id, sku) 主表，products_Trl(product_id, lang_code, name) 翻译表，联合查询可写成：
SELECT p.id, COALESCE(t1.name, t2.name, t3.name, 'N/A') AS name, p.sku FROM products p LEFT JOIN products_Trl t1 ON p.id = t1.product_id AND t1.lang_code = @LangCode LEFT JOIN products_Trl t2 ON p.id = t2.product_id AND t2.lang_code = 'zh' LEFT JOIN products_Trl t3 ON p.id = t3.product_id AND t3.lang_code = 'en';
- 顺序即 fallback 优先级：先找目标语言，没有则退到简体中文，再退到英文
- 所有
lang_code条件都写死在ON子句里，避免WHERE过滤掉主表记录 - 翻译表需在
(product_id, lang_code)上建唯一索引，否则性能急剧下降
容易被忽略的细节：排序规则与 Unicode 字段类型
即使列名拼对了、表结构也合理，查出来乱码或排序错位，大概率是字段没用 NVARCHAR 或没设对 COLLATE。
- 所有多语言内容字段必须声明为
NVARCHAR（不是VARCHAR），否则插入中文会变问号 - 如果业务要求按中文拼音排序、或德语 ß 当作 ss 处理，必须显式指定
COLLATE，例如：ORDER BY name COLLATE Chinese_PRC_CI_AS -
COLLATE不能只加在 SELECT 列上，JOIN 条件和 WHERE 比较也受其影响；混用不同排序规则会导致隐式转换失败
