预处理语句生命周期为PREPARE→EXECUTE→DEALLOCATE三阶段，执行计划在EXECUTE时生成且不跨连接复用；参数类型影响索引选择与优化效果；仅支持值占位，不支持动态表名/列名；PHP PDO默认模拟预处理会失效原生优化。
预处理语句在 MySQL 中的生命周期分三步
MySQL 执行 PREPARE → EXECUTE → DEALLOCATE PREPARE 是严格分阶段的，不是“一次编译、多次运行”那么简单。服务端会为每个 PREPARE 生成独立的执行计划缓存项，但该缓存**不跨连接复用**，也不自动失效于表结构变更。
-
PREPARE stmt_name FROM 'sql_string'：SQL 字符串被解析、语法检查、权限校验；若含参数占位符?，此时只做占位符绑定位置记录，**不展开任何变量、不查表、不生成执行计划** -
EXECUTE stmt_name [USING @var1, @var2]：真正触发查询优化器——根据当前参数值（如@var1的实际类型和值）生成执行计划；若已有同名stmt_name且参数特征未变（如都是 INT），可能复用上次计划；否则重新优化 -
DEALLOCATE PREPARE stmt_name：立即释放内存中的语句对象和关联的执行计划，后续再EXECUTE会报错Unknown prepared statement handler
为什么参数类型影响执行计划质量
MySQL 在 EXECUTE 阶段才拿到参数真实值和类型，而优化器依赖这些信息选择索引、估算行数。如果传入的参数类型与字段类型不一致（比如对 INT 字段传入字符串型 @id := '123'），会导致隐式类型转换，进而让索引失效。
- 显式声明变量类型能减少歧义：
SET @id := CAST(123 AS SIGNED);
- 对
VARCHAR字段使用LIKE ?时，若传入@pattern := '%abc'，优化器可能放弃使用前缀索引；换成LIKE CONCAT('%', ?)也无济于事——因为函数包裹会让索引失效 - 整数字段传浮点值（如
@val := 123.0）也可能触发隐式转换，尤其当字段是TINYINT或ENUM时
预处理语句无法规避的硬限制
很多开发者误以为预处理能绕过 SQL 注入或解决动态列名问题，其实它只处理“值”，不处理“结构”。所有涉及表名、列名、排序方向、LIMIT 偏移量等动态部分，仍需拼接字符串——而这恰恰是注入高发区。
-
PREPARE不支持动态表名：SET @table := 'users'; PREPARE stmt FROM 'SELECT * FROM ?'; -- 错误！? 只能代入值，不能代入标识符
- 想实现动态列排序，只能拼接：
SET @sql := CONCAT('SELECT * FROM users ORDER BY ', @col, ' ', @dir); PREPARE stmt FROM @sql;此时必须手动校验@col是否在白名单内（如IN ('id', 'name', 'created_at')），否则直接执行等于开后门 -
EXECUTE无法返回多个结果集（如存储过程中有多个SELECT），客户端收到第一个结果后就终止，其余被丢弃
连接断开时预处理语句自动销毁，但别依赖它
MySQL 协议规定：客户端连接关闭时，该连接上所有预处理语句自动 DEALLOCATE。这看似省心，但容易掩盖资源泄漏问题——比如长连接池中某次 PREPARE 失败未捕获，后续又反复尝试，可能堆积无效句柄。
- 可通过
SHOW STATUS LIKE 'Com_prepare_sql'和Com_execute_sql对比，判断是否真正在复用 - 监控
Threads_connected与Prepared_stmt_count比值异常升高，往往意味着应用没正确清理 - PHP PDO 默认启用
PDO::ATTR_EMULATE_PREPARES = true，此时根本没走 MySQL 原生预处理，而是客户端模拟——所有优化都失效，纯靠字符串替换
预处理语句的优化收益高度依赖参数稳定性与类型一致性，而不是“用了就快”。最常被忽略的是：同一连接内反复 PREPARE 同名语句不会报错，但会覆盖旧句柄，导致之前分配的资源泄露。
