concat不能拼接字段名，因其仅生成字符串值，不参与sql语法解析；字段名须预编译确定，动态列需用prepare+execute，安全拼接where条件应使用quote()防注入。
MySQL里用CONCAT拼接字段名会报错？
直接把CONCAT结果当列名用，SQL会报Unknown column 'xxx' in 'field list'——因为CONCAT是运行时函数，只生成字符串值，不参与SQL语法解析。字段名必须在预编译阶段就确定，不能靠函数“算出来”。
常见错误场景：想根据参数动态选name或full_name，写成SELECT CONCAT('user_', @field) FROM users，结果查出来是字符串字面量，不是真实字段。
- 真正需要的是动态SQL（即拼好整条语句再执行），不是字段级拼接
-
CONCAT适合拼接值、条件、表名、数据库名，但不能替代列别名或字段引用 - 如果只是想“选哪个字段由变量定”，优先考虑
CASE WHEN，而不是拼SQL
什么时候必须用PREPARE+EXECUTE动态SQL？
只有字段名、表名、排序字段、LIMIT偏移量这些语法成分需要运行时决定时，才绕不开PREPARE。比如管理后台按用户选择的字段导出数据，字段列表来自前端传参。
典型流程：拼字符串 → 预编译 → 执行 → 释放。中间任何一步出错都会中断，且无法用事务回滚已执行的EXECUTE。
- 拼接时务必用
CONCAT，别用+（MySQL里+是加法，不是字符串连接） - 表名/字段名若来自不可信输入，必须白名单校验，否则直接SQL注入
- 不能在存储函数里用
PREPARE，只能用在存储过程或客户端 - 示例：
SET @sql = CONCAT('SELECT ', @cols, ' FROM ', @table); PREPARE stmt FROM @sql; EXECUTE stmt; DEALLOCATE PREPARE stmt;
CONCAT拼接WHERE条件容易漏掉引号和转义
拼WHERE name = '张三'这种条件时，很多人直接CONCAT("name = '", @val, "'")，但如果@val含单引号（如O'Connor），SQL就断了。更糟的是，如果@val来自用户输入，这就是裸奔式SQL注入。
- 安全做法：用
QUOTE()包裹变量值，它会自动加引号并转义，比如QUOTE("O'Connor")返回'O''Connor' - 不要自己拼引号，也不要依赖
REPLACE(@val, "'", "''")，QUOTE更可靠 - 数值型字段不用
QUOTE，但要用CAST或显式类型判断，避免隐式转换引发索引失效 - 示例：
CONCAT('name = ', QUOTE(@name), ' AND status = ', @status)
动态SQL性能差，别在高频查询里用
每次PREPARE都会触发一次SQL解析、权限检查、执行计划生成，开销远高于普通查询。缓存也基本失效——哪怕@sql内容相同，只要语句字符串地址不同，就视为新SQL。
- 如果字段组合有限（比如就3种导出模板），提前写好3条固定SQL，用IF分支选执行哪条，比动态拼更快更稳
- MySQL 8.0+支持
PREPARE重用，但需同一连接、同名stmt，实际业务中很难保证 - 日志里看不到真实执行的SQL（只记
EXECUTE stmt），排查慢查时得额外抓@sql变量值
真要拼字段，先问自己：是不是其实只需要CASE或IFNULL就能覆盖90%场景？动态SQL是最后手段，不是快捷方式。
