prepare本身不防注入，仅支持占位符；必须配合参数绑定、白名单校验标识符、正确使用@变量并管理其生命周期才能真正防御sql注入。
PREPARE 语句本身不防注入，只有配合严格的参数绑定、白名单校验和变量生命周期管理，才能真正阻断动态 SQL 注入。
PREPARE + USING 是防注入的核心机制，不是语法糖
MySQL 的 PREPARE 只负责把字符串编译成语句模板，真正起防护作用的是 EXECUTE ... USING 这一环节：它强制将用户输入作为纯数据传入，不参与 SQL 解析。只要所有用户可控的值都走 ? 占位符 + USING @var，攻击者输入 admin' OR '1'='1 也只会被当作文本值匹配，不会改变查询逻辑。
-
?占位符不能加引号，写成"WHERE name = '?' "是错的；也不能出现在字符串内部 -
USING后只能跟已赋值的会话级用户变量（如@name_val），不能是字面量、表达式或存储过程参数名 - 变量必须在
EXECUTE前显式SET，且类型要匹配字段（比如 INT 字段别传字符串型@id） - 每次
PREPARE后建议紧跟DEALLOCATE PREPARE stmt，否则长连接中会累积句柄，最终触发ERROR 1437
表名、列名、ORDER BY 字段这些根本不能用 ? 占位
MySQL 明确禁止 SELECT * FROM ? 或 ORDER BY ?，直接报 ERROR 1064 (42000)。这些属于 SQL 结构部分，PREPARE 完全无法覆盖，必须靠白名单校验。
- 表名校验示例：
IF in_table NOT IN ('users', 'orders', 'logs') THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Invalid table name'; END IF; - 排序字段必须映射到固定集合，比如用
CASE WHEN in_sort = 'created_at' THEN 'created_at' ELSE 'id' END，而不是直接拼接 - 正则校验不可靠（
NOT REGEXP容易被绕过），白名单比清洗更稳妥 - 禁止用
TRIM()、REPLACE()“过滤”输入——my_table` --这类构造仍可穿透
常见踩坑点：拼接时机、变量作用域、隐式类型转换
很多看似用了 PREPARE 的代码依然高危，问题出在拼接发生在 PREPARE 之前，或者变量没管好。
- 错误写法：
SET @sql = CONCAT('SELECT * FROM users WHERE name = ''', in_name, '''');—— 恶意输入已在拼接时生效，PREPARE已无力回天 -
PREPARE只认会话级用户变量（@sql），不接受局部变量（DECLARE v_sql VARCHAR(1000)）或CONCAT()直接入参 - 循环中复用同一组
@var但没重置，上次执行的值会污染本次查询结果 -
LIMIT ?, ?中第一个参数（offset）必须转为整数并校验 ≥ 0，否则 MySQL 隐式转成 0 或报错，可能暴露逻辑或绕过分页限制
真正安全的动态 SQL 不是“用了 PREPARE 就万事大吉”，而是每处拼接都有明确校验依据，每个 ? 都对应一个受控变量，每个 @var 都有清晰的生命周期。最容易被忽略的是：标识符校验必须独立于参数绑定，且不能依赖任何客户端侧的“过滤”逻辑。
