MySQL执行动态SQL必须经PREPARE三步：SET @sql→PREPARE stmt FROM @sql→EXECUTE stmt USING；表名列名须白名单校验，值参数用USING绑定，且须DEALLOCATE释放资源。
MySQL不支持直接执行拼接的SQL字符串
你不能写 SET @sql = 'SELECT * FROM users WHERE id = 1'; EXECUTE @sql; —— 这会报错 ERROR 1064 或 ERROR 1295。MySQL 的 EXECUTE 只接受预处理语句句柄（比如 stmt），不接受字符串变量。它根本不会尝试去“解释”一个字符串为 SQL，这是语法层面的硬性限制。
PREPARE 是唯一能绕过语法校验时机的机制
PREPARE stmt FROM @sql 并不是执行，而是让 MySQL 对 @sql 字符串做一次完整的解析、权限检查和执行计划缓存。这步成功，说明表名、字段名、语法结构在当前上下文是合法的；失败则立刻抛错，比如表不存在或列名错——这种校验发生在真正 EXECUTE 之前，避免了运行时才发现结构问题。
-
@sql必须是用户变量（@xxx），不能是DECLARE声明的局部变量 - 不能写成
PREPARE stmt FROM CONCAT('SELECT * FROM ', @table)，必须先SET @sql = CONCAT(...) - 拼接时漏空格、少引号、多逗号，都会导致
PREPARE阶段就失败，而不是等到EXECUTE才出问题
动态结构和动态数据必须分离处理
MySQL 明确禁止用 ? 占位符替换表名、列名、ORDER BY 字段或 LIMIT 参数——这些属于“SQL 结构”，只能靠字符串拼接进 @sql；而 WHERE 条件值、INSERT 的字段值等“动态数据”，必须走 EXECUTE ... USING @var。这种强制分离，是 MySQL 实现参数化查询安全性的底层设计前提。
- 错误写法：
PREPARE stmt FROM 'SELECT * FROM ? WHERE name = ?';→ERROR 1064 - 正确做法：表名白名单校验后拼入
@sql，name值用USING @name_val绑定 -
USING后只能跟已赋值的用户变量，不能是字面量（如USING 'admin'报错）
不释放 PREPARE 会导致后续调用直接失败
每次 PREPARE 都会在当前会话中注册一个语句句柄，不 DEALLOCATE PREPARE stmt 就一直占着资源。在存储过程中循环或多次分支调用时，很容易触发 ERROR 1243: Unknown prepared statement handler 或 MySQL server has gone away。
- 重复
PREPARE stmt FROM @sql不会自动覆盖，必须先DEALLOCATE，或改用动态命名（如CONCAT('stmt_', UNIX_TIMESTAMP())） - 异常路径也要清理：建议在存储过程开头定义
DECLARE EXIT HANDLER FOR SQLEXCEPTION，确保出错时仍执行DEALLOCATE - MySQL 8.0.13+ 支持
DROP PREPARE IF EXISTS stmt，但兼容性考虑，显式DEALLOCATE更稳妥
关键点其实就一个：MySQL 把“SQL 结构合法性检查”和“数据值绑定执行”拆成了两个不可合并的阶段，而 PREPARE 是唯一能触达第一阶段的入口。跳过它，就等于放弃语法校验、执行计划复用和参数化隔离——不是“不方便”，而是根本走不通。
