MySQL存储过程PREPARE不能直接拼接变量，必须通过用户变量@sql中转；表名列名等标识符需用REGEXP校验防注入；EXECUTE USING只支持已赋值的用户变量，且须配对DEALLOCATE PREPARE。
MySQL 存储过程中 PREPARE 不能直接拼接变量？
不能。MySQL 的 PREPARE 语句要求 SQL 字符串必须是**用户变量（@var）**，且该变量值在 PREPARE 执行前必须已赋值为完整、合法的 SQL 字符串；你不能把表名、列名、WHERE 条件这些动态部分直接塞进字符串字面量里再 PREPARE —— 那会报错 ERROR 1064 (42000) 或 ERROR 1295 (HY000): This command is not supported in the prepared statement protocol yet。
真正能动态的部分只有：WHERE 值、LIMIT 数、ORDER BY 表达式（需谨慎）、INSERT VALUES 具体值。表名、列名、数据库名这类“结构标识符”必须靠字符串拼接 + 用户变量中转。
SET @sql = CONCAT('SELECT * FROM ', @table_name, ' WHERE id = ?');- 拼完后必须用
SET @sql = @sql;确保它是用户变量，再PREPARE stmt FROM @sql; - 如果漏了
@sql这层中转，直接PREPARE stmt FROM CONCAT(...)会语法报错
如何安全拼接表名/列名并避免 SQL 注入？
MySQL 存储过程没有参数化标识符（parameterized identifiers），所以你必须自己校验输入是否符合标识符规范，否则拼进去就是注入漏洞。别信“只是内部系统就无所谓”——权限失控或日志泄露都可能被利用。
- 用
REGEXP '^[a-zA-Z_][a-zA-Z0-9_]*$'检查@table_name和@col_name，不匹配就SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Invalid identifier'; - 不要用
REPLACE()或TRIM()“清洗”，它们无法阻止my_table` --这类绕过 - 如果来源是配置表或固定枚举，优先用
CASE WHEN映射，而不是拼接：SET @table_name = CASE @input_type WHEN 'user' THEN 't_user' WHEN 'order' THEN 't_order' ELSE NULL END;
EXECUTE stmt USING 只支持标量值，不支持表达式或 NULL
USING 后只能跟用户变量（@var），且这些变量值必须是具体数据类型（INT、VARCHAR 等），不能是函数调用、子查询或 NULL 字面量（NULL 要先赋给变量）。
- 错误写法：
EXECUTE stmt USING 123, NOW();→ 报错ERROR 1210 (HY000): Incorrect arguments to EXECUTE - 正确写法：
SET @id = 123; SET @ts = NOW(); EXECUTE stmt USING @id, @ts; - 如果某个参数可能为
NULL，必须显式赋值：SET @opt_val = IFNULL(input_param, NULL);，再USING @opt_val -
USING的变量个数、顺序、类型必须和?占位符完全一致，少一个或多一个都会失败
执行完记得 DEALLOCATE PREPARE，否则会内存泄漏
每个 PREPARE 都会占用服务器端会话资源，不释放会导致 max_prepared_stmt_count 耗尽，后续所有 PREPARE 都报 ERROR 1461 (42000): Can't create more than max_prepared_stmt_count statements。这不是连接断开就自动清理的。
- 必须配对使用：
PREPARE→EXECUTE→DEALLOCATE PREPARE stmt; - 如果中间出错（比如
EXECUTE报错），DEALLOCATE仍要执行，建议包在DECLARE EXIT HANDLER里 - 别用
stmt作为多个PREPARE的通用名，容易覆盖；不同语句用不同名字：stmt_insert,stmt_select
实际跑通的关键就三点：用 @sql 中转拼接、标识符严格校验、USING 只传变量不传表达式。最容易被忽略的是错误处理路径下的 DEALLOCATE 缺失，以及把 NOW() 这种函数直接塞进 USING。
