prepare+execute必须配using才安全，mysql仅支持?占位符且需using绑定变量；禁用concat拼接用户输入，静态sql优先；pymysql调用须用callproc或%s参数化，不可字符串格式化。
MySQL存储过程里用PREPARE+EXECUTE必须配USING
动态SQL在存储过程中无法避免时，PREPARE+EXECUTE是唯一安全路径，但光有这两步远远不够——漏掉USING或写错占位符，就等于把门敞开。MySQL不支持像SQL Server那样在SQL字符串里声明参数名，它只认?这个唯一占位符，且必须靠USING绑定变量。
常见错误包括：
- 把
?写成'?'或拼进字符串里，比如SET @sql = CONCAT('WHERE name = ''?', '''');——这会让?变成字面量，失去参数化意义 -
USING后传入表达式，如USING UPPER(p_name)，MySQL直接报错ERROR 1210 (HY000): Incorrect arguments to EXECUTE - 在循环中反复
PREPARE/DEALLOCATE，性能暴跌，且容易因句柄未释放引发ERROR 1475 (HY000): Cannot execute statement: impossible to write to binary log
静态SQL比动态SQL更安全也更高效
只要查询结构固定，优先写死条件字段和表名，用参数直接传值。比如搜索用户按用户名查，就别拼@sql，直接写WHERE username = p_username。这种写法数据库在解析阶段就确定执行计划，参数被严格当作数据处理，天然免疫注入。
适用场景明确：
- 字段名、表名、运算符（
=、LIKE、IN）不随输入变化 - 不需要运行时决定是否加
ORDER BY或LIMIT - 参数类型与长度可预估（如
VARCHAR(50)），避免隐式转换绕过校验
一旦开始考虑“要不要加AND status = ?”，说明逻辑已滑向动态拼接边缘，该拆成多个专用过程，而不是在一个过程里堆IF判断拼SQL。
PyMySQL调用存储过程时仍需参数化传参
很多人以为“用了存储过程就万事大吉”，结果在Python里用cursor.execute("CALL search_user('%s')" % user_input)，照样中招。存储过程防不住应用层的字符串拼接——它只管自己内部怎么写，不管你怎么调它。
正确姿势只有两种：
- 用
cursor.callproc('search_user', [user_input])，由驱动自动处理参数绑定 - 或用
cursor.execute("CALL search_user(%s)", [user_input])，确保%s是PyMySQL的占位符，不是Python字符串格式化
注意：callproc不支持返回结果集直接遍历，若过程含SELECT，得配合cursor.nextset()跳过无用结果集，否则fetchone()会报InterfaceError: No result set to fetch from。
权限收紧不能弥补存储过程本身的缺陷
给应用账号只授EXECUTE权限，确实能限制它删表建库，但这对注入毫无防御力。只要过程本身用CONCAT拼接了in_name，攻击者传入admin' UNION SELECT password FROM mysql.user -- ，照样能拖库。
真正关键的检查点只有两个：
- 过程体里有没有出现
CONCAT、+、REPLACE等字符串操作函数包裹用户输入 - 所有
PREPARE语句的@sql变量里是否只含固定SQL模板，且?之外没有插入任何变量内容
别依赖“过程+权限”组合拳，它只是纵深防御的一环，不是免死金牌。最脆弱的环节永远在代码里写SET @sql = CONCAT(...)的那一行。
