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 用，都容易卡住或报错。
