Prepared Statement跳过词法分析、语法分析、语义检查和查询重写四步，仅在PREPARE阶段执行一次，后续EXECUTE仅绑定参数并执行，天然防注入。
预处理语句不是“可选优化”，而是重复执行同结构 SQL 时的刚需——它直接跳过词法/语法解析和重写阶段，且参数与 SQL 结构物理隔离，天然防注入。
Prepared Statement 跳过了哪些 MySQL 执行步骤？
普通 SQL（即时语句）每次执行都要走完整流程：词法分析 → 语法分析 → 语义检查 → 查询重写 → 优化器生成执行计划 → 执行。其中前四步在预处理语句中只做一次。
Prepared Statement 的 PREPARE 阶段完成解析与重写后，后续每次 EXECUTE 只需做两件事：绑定参数值、触发优化器（可能复用缓存计划）、执行。GaussDB(for MySQL) 等增强版还能缓存最终执行计划，进一步跳过优化阶段。
这意味着： - 单条语句执行 100 次，传统方式做 100 次解析+重写；预处理只做 1 次 - 网络传输量大幅下降：只需传参数值，不用重复传整个 SQL 字符串 - 服务器 CPU 和内存压力明显降低，尤其在高并发批量操作场景下
为什么 PreparedStatement 能真正防 SQL 注入？
不是靠转义、不是靠过滤，而是数据库协议层的硬隔离：SQL 模板在 PREPARE 阶段就固定了语法树结构，参数值在 EXECUTE USING 阶段仅作为纯数据填入，**绝不会被送进 SQL 解析器**。
常见错误仍会导致失效：
- 用字符串拼接构造 PREPARE 的 SQL 字符串，比如 CONCAT('SELECT * FROM t WHERE id = ', @user_input)
- 在客户端用 mysqli_query() 拼接后再传给 PREPARE，等于白用
- 使用 PDO 但开启模拟预处理（PDO::ATTR_EMULATE_PREPARES => true），此时参数仍在 PHP 层拼接，未交由 MySQL 服务端真正预编译
MySQL 原生命令行里怎么安全用 PREPARE？
原生 PREPARE/EXECUTE 用法简单，但极易踩坑：
正确姿势：
- PREPARE stmt FROM 'SELECT * FROM users WHERE status = ? AND created_at > ?'
- SET @s = 'active', @t = '2024-01-01'
- EXECUTE stmt USING @s, @t
- DEALLOCATE PREPARE stmt
注意点：
- 占位符 ? 不能出现在表名、列名、ORDER BY 子句等结构位置，这些必须静态写死或通过应用层逻辑控制
- USING 后只能跟用户变量（@var），不能直接写字面量或表达式
- 同一个 stmt 名重复 PREPARE 会报错，需先 DEALLOCATE 或换名
Connector/NET 或 JDBC 中 prepare() 调用失败的常见原因
应用代码里调 cmd.Prepare() 或 conn.prepareStatement() 报错，往往不是语法问题，而是环境或配置层面卡住：
典型原因：
- MySQL 服务端未启用预处理支持（极少见，5.5+ 默认开启）
- 连接字符串漏掉 useServerPrepStmts=true（MySQL Connector/J）或 UseAffectedRows=true 等关键开关
- 参数类型不匹配：比如给 INT 字段绑了字符串值，且驱动未自动转换（尤其 .NET 中未显式指定 MySqlDbType.Int32）
- 多次 Prepare() 同一命令但未清空已有参数，旧参数残留干扰新执行
最稳妥做法：每个 MySqlCommand 实例只 Prepare() 一次，之后只改 Parameters[i].Value，不重设 CommandText 或重新 AddParameter。
真正难的不是写对第一行 PREPARE，而是确保所有动态部分都落在占位符里，且整个链路——从应用传参、驱动配置、到服务端执行——没有一处偷偷把参数又拼回 SQL 字符串里。
