SQL中不能直接用变量作列名，因列名须在解析阶段确定；需通过动态SQL拼接（如MySQL的PREPARE/EXECUTE或PostgreSQL的format()/EXECUTE），并严格校验白名单或系统表，避免注入风险。
SQL里不能直接用变量当列名
绝大多数SQL引擎（MySQL、PostgreSQL、SQL Server）在标准SELECT语句中不支持把变量或表达式当作列名使用。比如写 SELECT @col_name FROM table，实际查出来的是变量值本身，不是以该值为名的字段——这常被误认为“动态列名”，其实是字符串字面量。
真正需要动态列名，通常出现在报表导出、宽表转置、或前端传入字段列表的场景。核心思路是：**列名必须在SQL解析阶段确定，所以得靠服务端拼SQL字符串，再执行**。
MySQL中用PREPARE + EXECUTE拼接列名
MySQL支持动态SQL，但必须分三步：构造SQL字符串 → 预编译 → 执行。注意：PREPARE 只能用于会话级，且不能嵌套在存储函数里（仅限存储过程或客户端直连）。
- 列名需手动转义防注入：
CONCAT('`', REPLACE(@col, '`', '``'), '`') - 不能拼在WHERE或ORDER BY里就以为安全——列名拼接本身已是高危操作，务必白名单校验
- 示例：假设要查
user_id和一个运行时传入的列@target_col = 'status'
SET @target_col = 'status';
SET @sql = CONCAT('SELECT user_id, ', '`', @target_col, '`', ' FROM users');
PREPARE stmt FROM @sql;
EXECUTE stmt;
DEALLOCATE PREPARE stmt;
PostgreSQL用format() + EXECUTE做安全拼接
PostgreSQL更强调安全性，format() 提供 %I（标识符）和 %L（字面量）占位符，自动处理引号和转义。但动态列名仍只能在DO块或函数内使用，不能用于普通查询。
- %I 会把输入转成双引号包围的合法标识符，如
format('SELECT id, %I FROM t', 'order')→SELECT id, "order" FROM t - 不可省略EXECUTE所在的匿名代码块（DO block）或函数上下文
- 若列名来自用户输入，先查系统表
pg_attribute确认字段真实存在，避免报错或越权
DO $$
DECLARE
col_name TEXT := 'created_at';
BEGIN
EXECUTE format('SELECT id, %I FROM orders LIMIT 5', col_name);
END $$;
更稳妥的替代方案：用JSON或应用层处理
硬拼SQL有注入风险、调试困难、缓存失效快。多数情况下，应该避开动态列名：
- 用
json_object_agg()（PostgreSQL）或JSON_OBJECT()（MySQL 5.7+）把整行转成JSON，由应用决定取哪些key - 固定返回所有可能字段（如
SELECT id, name, status, created_at, ...），在应用层按需过滤键名 - 对宽表场景，考虑用
UNPIVOT/crosstab()预定义结构，而非运行时拼列
真正卡住的地方往往不是语法怎么写，而是没想清楚：这个“动态”到底是业务需求，还是偷懒绕开接口设计的结果。
