MySQL 8.0 动态SQL必须经PREPARE→EXECUTE→DEALLOCATE完整链路，PREPARE仅接受用户变量（如@sql），不支持字面量、局部变量或表达式；表名列名须白名单校验后拼接，?仅替换值不能替换标识符。
MySQL 8.0 里不能直接执行拼接好的 SQL 字符串，必须走 PREPARE → EXECUTE → DEALLOCATE PREPARE 这个完整链路；跳过 PREPARE 或误用变量类型，90% 的报错都出在这两步。
PREPARE 只接受用户变量，不能传字符串字面量或局部变量
常见错误现象：ERROR 1064 (42000) 或 ERROR 1210 (HY000)，本质是 MySQL 在解析阶段就拒绝了非法输入。
-
PREPARE stmt FROM 'SELECT * FROM users WHERE id = ?'✅ 合法：字符串字面量可直接用 -
SET @sql = 'SELECT * FROM users WHERE id = ?'; PREPARE stmt FROM @sql;✅ 合法：必须通过用户变量@sql传递 -
PREPARE stmt FROM CONCAT('SELECT * FROM ', @table, ' WHERE id = ?');❌ 非法：CONCAT()是表达式，PREPARE不接受 - 在存储过程中用
DECLARE sql_str TEXT; PREPARE stmt FROM sql_str;❌ 非法：PREPARE不认局部变量
正确做法永远是先 SET @sql = CONCAT(...)，再 PREPARE stmt FROM @sql。中间不能有任何计算或逻辑判断混入拼接过程。
表名、列名、ORDER BY 字段必须手动拼接，且必须白名单校验
占位符 ? 只能替换值，不能替换标识符——这是 MySQL 协议层硬限制，不是语法糖缺失。
- 错误写法：
SELECT * FROM ? WHERE id = ?→ERROR 1064，解析失败 - 正确流程：先校验
@table_name是否合法，再拼进@sql - 推荐白名单校验：
SET @allowed = 'users,orders,products'; IF FIND_IN_SET(@input, @allowed) = 0 THEN SET @sql = "SELECT 'invalid table' AS result"; END IF; - 若用正则粗筛：
@table_name REGEXP '^[a-zA-Z0-9_]+$'，但仅作辅助，不能替代白名单 - 拼接时注意空格和引号：
CONCAT('SELECT ', @columns, ' FROM ', @table_name, ' WHERE name = ?')，漏空格会变成FROMusers
字符串值要用单引号包裹，内部单引号必须转义为两个单引号（''），QUOTE() 返回的是带引号的字符串，不能直接塞进 @sql。
EXECUTE USING 只支持用户变量，且参数数量顺序必须与 ? 严格一致
常见翻车点：传参用字面量、变量未提前赋值、? 个数和 USING 变量数对不上。
- 错误：
EXECUTE stmt USING 123→ERROR 1210 - 错误：
SET @id = NULL; EXECUTE stmt USING @id→ 可能查不到数据，且不报错（隐式转换为 0） - 正确：
SET @id = 123; EXECUTE stmt USING @id; - 多个参数：
SET @a = 1, @b = 'abc'; EXECUTE stmt USING @a, @b;，顺序和数量必须和?完全一致 - 字段类型不匹配时 MySQL 会隐式转换：
INT字段传@x = '123abc'→ 截成123；传'abc'→ 变成0，无警告
执行后想查影响行数，立刻跟 SELECT ROW_COUNT();；想取 SELECT 结果，只能由客户端接收，无法用 INTO 捕获（除非进存储过程+游标，代价高）。
存储过程中反复 PREPARE 必须 DEALLOCATE 或动态命名
不释放句柄会导致“SQL statement not found”、内存堆积，尤其在循环或高并发场景下。
- 每次
PREPARE stmt FROM @sql都注册新句柄，同名会覆盖但旧句柄仍驻留 - 安全写法一：
DEALLOCATE PREPARE IF EXISTS stmt;放在PREPARE前 - 安全写法二：动态命名，如
SET @stmt_name = CONCAT('stmt_', UNIX_TIMESTAMP(), '_', RAND()); PREPARE @stmt_name FROM @sql; - 更优策略：优先用
IF/CASE分支 + 静态 SQL，只在真正需要动态切换表/字段时才走PREPARE - MySQL 8.0+ 对重复 SQL 语句会尝试复用执行计划，但拼接后几乎总是新语句，缓存收益有限
最易被忽略的是：PREPARE 阶段就做语法和对象校验（比如表是否存在、字段名是否拼错），错误会在这里暴露，而不是等到 EXECUTE；很多人卡在 EXECUTE 报错，其实该往前看 PREPARE 是否成功。
