MySQL存储过程不能直接EXECUTE字符串，必须先PREPARE生成语句句柄；EXECUTE仅接受句柄而非字符串变量，且PREPARE阶段即校验语法与对象存在性，失败立即报错。
MySQL存储过程里不能直接执行拼好的SQL字符串，必须走 PREPARE + EXECUTE 这套流程，否则会报 Unknown prepared statement 或 Incorrect arguments to EXECUTE。
为什么不能 SET @sql = '...' 然后直接 EXECUTE @sql
因为 EXECUTE 只接受预处理语句句柄（比如 stmt），不接受字符串变量。你写 EXECUTE @sql 语法上就错——MySQL会提示 Incorrect arguments to EXECUTE。必须先用 PREPARE stmt FROM @sql 把字符串编译成可执行对象，再 EXECUTE stmt。
-
PREPARE阶段会做语法检查、表/列存在性校验，失败立刻报错（比如表名错、字段不存在） - 同一个语句名重复
PREPARE会覆盖前一个，不DEALLOCATE也不会报错，但建议显式释放避免句柄堆积 - 若在存储过程中跨
IF分支复用同名stmt（比如IF ... THEN PREPARE stmt ... ELSE PREPARE stmt ...），第二次EXECUTE会报Unknown prepared statement
如何安全传参：USING vs 字符串拼接
值类参数（WHERE 右边、ORDER BY 后的数字、LIMIT 的偏移量）优先用 USING；表名、列名、排序字段、分组字段等标识符必须拼进 @sql 字符串，且需手动白名单校验。
-
USING自动转义 NULL 和特殊字符，防注入，但只支持值替换，且变量必须是用户变量（@var），不能直接用存储过程参数（得先SET @val := p_id） -
USING中传NULL，生成的是IS NULL而非= NULL，逻辑可能意外，注意判空方式 - 拼接表名时，若来源不可信（如来自参数
p_table），必须严格比对白名单：IF p_table NOT IN ('users', 'orders', 'logs') THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Invalid table name'; END IF;
动态SQL常见错误现象与修复
典型报错不是“语法错”，而是运行时才暴露，比如 Table 'db.unknown_table' doesn't exist 或 Unknown column 'xxx' in 'where clause'——这些都在 PREPARE 阶段抛出，不是 EXECUTE 时。
- 漏单引号：拼
WHERE name = '+p_name+'时，若p_name含单引号或为空，SQL 直接崩。改用USING就没这问题 - 变量作用域错：在
IF块内定义的@sql，外面PREPARE会报Unknown column '@sql'，所有@sql必须在作用域顶层声明并赋值 - 多语句限制：
PREPARE不支持分号分隔的多条语句，比如INSERT; UPDATE会直接报错，只能单条执行
存储过程里执行外部传入的SQL字符串（如 exec_ddl 类型需求）
这是最简场景：只接收一个 sqlstmt 参数，不做任何拼接，原样执行。适合 DDL 或简单 DML。
- 必须用用户变量中转：
SET @sql = sqlstmt;，不能PREPARE stmt FROM sqlstmt（参数名不是字符串变量） - DDL（如
CREATE TABLE）也能执行，但注意事务：MySQL 中 DDL 会隐式提交当前事务 - 若需反复调用，建议每次用不同句柄名（如
stmt_123），或固定名但加DEALLOCATE PREPARE stmt前置清理，避免句柄残留
真正容易被忽略的是：预处理语句只在当前会话有效，且 PREPARE 的校验粒度很细——哪怕只是临时表名拼错、字段少了个下划线，都会在 PREPARE 那步卡住，而不是等到 EXECUTE 才发现。别省那一步校验。
