mysql执行SQL时prepare和execute有什么区别_预处理流程说明

prepare 编译 sql 模板并缓存执行计划，execute 代入参数执行；二者必须成对使用，句柄仅会话有效，需用 deallocate 显式释放或会话结束自动清理。

prepare 是编译 SQL 模板，execute 是带参运行

mysql 的 PREPARE 不执行语句，只做语法解析、参数占位符（?）绑定、生成执行计划缓存；而 EXECUTE 才真正把具体值代入、查表、返回结果。两者必须成对出现，不能跳过 PREPARE 直接 EXECUTE —— 否则报错 Unknown prepared statement handler。

• PREPARE stmt_name FROM 'select * FROM t WHERE id = ?'：只校验 SQL 合法性，不检查表是否存在或字段名是否正确（部分检查延迟到 EXECUTE）
• EXECUTE stmt_name using @a：此时才校验 @a 类型兼容性、表结构是否匹配、权限是否足够
• 同一 stmt_name 可被多次 EXECUTE，每次传不同参数，避免重复解析开销

预处理语句生命周期由会话控制

用 PREPARE 创建的语句句柄（如 stmt_name）只在当前连接（session）内有效，断连即销毁。它不共享、不跨线程、不进系统表 —— 所以不存在“全局预处理语句”概念。

• 显式释放用 DEALLOCATE PREPARE stmt_name，否则直到会话结束才自动清理
• 若忘记 DEALLOCATE 且反复 PREPARE 同名语句，会报错 SQL Error [HY000]: Prepared statement already exists
• 存储过程里用 PREPARE 要特别注意作用域：局部变量不能直接用于 USING，得先赋值给用户变量 @var

参数只能是用户变量，不能是字面量或表达式

EXECUTE ... USING 后面必须跟用户变量（@name），不能写 USING 123 或 USING @a + 1，否则报错 SQL Error [HY000]: Incorrect arguments to EXECUTE。

• 正确写法：

  SET @id = 123; EXECUTE stmt_name USING @id;

• 字符串需加引号再赋值：

  SET @name = 'alice'; EXECUTE stmt_name USING @name;

• NULL 值要显式赋值：

  SET @val = NULL; EXECUTE stmt_name USING @val;

和客户端预处理（如 JDBC PreparedStatement）不是一回事

MySQL 协议层的 PREPARE/EXECUTE 是服务端功能，而 JDBC、Python 的 cursor.execute("SELECT ?", [x]) 是客户端模拟：它们通常把参数拼进 SQL 字符串再发普通查询，除非显式启用服务端预处理（如 MySQL Connector/J 加 useServerPrepStmts=true）。

• 服务端预处理能规避 SQL 注入、减少解析压力，但有额外 round-trip 开销，小查询未必划算
• 某些旧版驱动默认禁用服务端预处理，即使写了 ? 也走文本协议，此时 SHOW PROCESSLIST 看不到 Prepare 状态
• EXPLAIN 对预处理语句无效，必须用 EXPLAIN EXECUTE stmt_name USING @x（MySQL 8.0.22+ 支持）

实际用的时候，别以为写了 PREPARE 就一定更安全或更快——参数类型不匹配、没及时释放句柄、误当客户端 API 用，都容易卡住或报错。