PREPARE语句必须通过SET @sql=CONCAT(...)拼接完整SQL字符串再执行，表名列名等标识符需白名单校验后拼入@sql，值参数用?占位符配合EXECUTE USING绑定，且须DEALLOCATE释放资源。
PREPARE 语句必须在存储过程内用 SET 拼接完整 SQL 字符串
MySQL 的 PREPARE 不接受变量直接拼在语句字面量里，比如 PREPARE stmt FROM 'SELECT * FROM ?' 是非法的——问号只在 EXECUTE 时占位，不能出现在 PREPARE 的字符串中。你得先用 CONCAT() 把表名、字段名等动态部分拼进一个字符串变量，再把这个变量传给 PREPARE。
常见错误是写成：PREPARE stmt FROM 'SELECT * FROM ' + table_name（语法错）或漏掉 SET @sql = CONCAT(...) 直接传参数名。
- 动态部分（如表名、列名）必须拼进
@sql字符串，不能靠 EXECUTE 的 USING 传入 -
@sql必须是用户变量（以 @ 开头），且作用域需覆盖 PREPARE → EXECUTE → DEALLOCATE 全流程 - 拼接时注意单引号转义：如果字段值含单引号，要用
REPLACE(val, "'", "''")或改用参数化方式（见下条）
EXECUTE 需区分“动态结构”和“动态数据”两种参数
结构类动态（表名、ORDER BY 字段、LIMIT 偏移）只能拼进 @sql 字符串；而数据类动态（WHERE 条件值、INSERT 的值）应走 USING 子句，由 MySQL 自动处理类型和转义。
例如想查某用户名下的记录：SET @sql = CONCAT('SELECT * FROM users WHERE name = ?'); 然后 EXECUTE stmt USING @name; —— 这样比把 @name 拼进字符串更安全，避免 SQL 注入和引号混乱。
- USING 后只能跟用户变量（
@var），不能是局部变量（DECLARE v VARCHAR(50)） - USING 变量个数和 ? 占位符个数必须严格一致，否则报错
Column count doesn't match value count at row 1 - 如果动态语句不含数据参数，
EXECUTE stmt;就行，不必写USING
必须显式 DEALLOCATE PREPARE，否则会报 “MySQL server has gone away”
每次 PREPARE 都会占用会话级资源，不释放会导致后续 PREPARE 失败（错误号 1243：Unknown prepared statement handler），尤其在循环中反复 PREPARE 时极易触发。
典型写法是：在 EXECUTE 后紧跟 DEALLOCATE PREPARE stmt;。如果存储过程中有多个分支，每个分支的末尾都得确保执行 DEALLOCATE，或者统一用 EXIT HANDLER 捕获异常后清理。
- 不能依赖连接断开自动释放——存储过程在单次连接内执行，不释放就一直占着
- stmt 名称可以复用，但重复 PREPARE 同名 stmt 前必须先 DEALLOCATE，否则报错
Duplicate prepared statement - 若 EXECUTE 报错，DEALLOCATE 仍需执行，否则该 stmt 在本次会话中永久失效
存储过程里用 PREPARE 的性能和兼容性陷阱
PREPARE 在存储过程中无法被查询缓存，每次调用都会重新解析 SQL；且 MySQL 8.0 之前不支持在 PREPARE 字符串里用 CTE（WITH 子句）、窗口函数，也不支持 PREPARE 调用存储函数（报错 This function has none of DETERMINISTIC...）。
真正需要动态结构的场景其实不多：比如通用分页封装、按租户切换表名、审计日志表按月轮转。多数情况下，用 IF/ELSE 判断+静态 SQL 更快也更可读。
- 高并发下频繁 PREPARE/DEALLOCATE 会加重 parser 和权限检查开销
- mysqldump 或某些 ORM（如 Django）可能无法正确解析含 PREPARE 的存储过程定义
- 如果只是 WHERE 条件变化，优先考虑
IF ... THEN ... ELSE分支 + 多条静态 SELECT，而非硬上 PREPARE
实际用的时候，最常卡住的地方不是语法，而是忘了 @sql 变量没设初值、USING 变量类型不匹配、或者 DEALLOCATE 被异常跳过——这些都不会立刻报错，但会让下一次调用莫名其妙失败。
