mysql中prepare/execute不支持变量拼接表名列名，需手动校验或白名单控制；数据值可用?参数化，结构部分须concat拼接并加反引号；execute using仅接受用户变量；务必deallocate prepare防资源泄漏。
MySQL里PREPARE和EXECUTE不能直接用普通变量拼接SQL
你写SET @sql = CONCAT('SELECT * FROM ', @table_name);看似合理，但PREPARE stmt FROM @sql执行时，如果@table_name含非法字符、空值或未初始化，会直接报错ERROR 1064 (42000)。根本原因是：MySQL在预处理阶段不解析变量内容，只做字符串拼接，拼出来的SQL必须语法完整且表/列名真实存在。
- 表名、列名等标识符不能用
?占位符——PREPARE只支持数据值参数化，不支持结构动态化 - 必须手动校验
@table_name是否为合法标识符（例如用正则过滤字母/数字/下划线，且不以数字开头） - 生产环境强烈建议白名单控制可执行的表名，比如：
IF @table_name NOT IN ('users', 'orders', 'logs') THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Invalid table name'; END IF;
正确拼接表名/列名要用CONCAT + QUOTE或自定义清洗函数
数据值（如WHERE条件中的字符串）可用?安全传入；但结构部分（表名、ORDER BY字段、GROUP BY列）必须拼进SQL字符串本身。这时QUOTE()没用——它加的是单引号，而表名需要的是反引号。
- 安全拼接表名示例：
SET @sql = CONCAT('SELECT id, name FROM `', REPLACE(@table_name, '`', ''), '` WHERE status = ?'); - 更稳妥的做法是写个存储函数清理标识符：
CREATE FUNCTION safe_ident(s TEXT) RETURNS TEXT DETERMINISTIC RETURN IF(s REGEXP '^[a-zA-Z_][a-zA-Z0-9_]*$', s, 'invalid'); - 拼完务必检查：
SELECT @sql;——别跳过这步，很多错误就卡在这儿
EXECUTE ... USING只接受变量，不接受字面量或表达式
你不能写EXECUTE stmt USING 'active';，MySQL会报ERROR 1210 (HY000): Incorrect arguments to EXECUTE。所有USING后的参数必须是用户变量（@var），且数量、顺序要和SQL中?完全一致。
- 正确写法：
SET @status = 'active'; EXECUTE stmt USING @status; - 多个参数按位置匹配：
SET @min = 100; @max = 500; EXECUTE stmt USING @min, @max; - 如果参数类型不匹配（比如把NULL传给NOT NULL字段），错误可能延迟到执行时才暴露，不是预编译时报
记得显式DEALLOCATE PREPARE，否则会累积占用会话资源
每个PREPARE都会在当前连接内创建一个准备语句对象，不释放会持续占用内存，且同名stmt重复PREPARE会报ERROR 1243 (HY000): Unknown prepared statement handler（因旧stmt未释放）。
- 标准流程应是：
SET @sql = ...; PREPARE stmt FROM @sql; EXECUTE stmt USING ...; DEALLOCATE PREPARE stmt; - 在存储过程中，若同一段逻辑被多次调用，务必在每次
PREPARE前加IF EXISTS(SELECT 1 FROM information_schema.prepared_statements WHERE STATEMENT_NAME = 'stmt') THEN DEALLOCATE PREPARE stmt; END IF;（但注意：5.7+才支持查询information_schema.prepared_statements） - 临时表场景下更要小心：
PREPARE后创建的临时表，在DEALLOCATE后依然存在，但后续EXECUTE会失败——因为stmt已销毁
实际中最容易被忽略的是标识符拼接时的SQL注入风险和DEALLOCATE遗漏。哪怕只是调试，也别依赖客户端自动断连来“清理”准备语句。
