预处理语句是mysql中必须启用的安全与性能底线，通过结构与参数分离，既杜绝sql注入，又实现“一次编译、多次执行”以减少解析开销；其正确使用需注意变量绑定、连接生命周期及动态in子句等限制。
预处理语句在 MySQL 项目中不是“可选优化”，而是必须启用的安全与性能底线——只要涉及用户输入或循环查询，不使用 PREPARE/EXECUTE 或语言层的等价接口（如 PDO::prepare、mysql_stmt_prepare），就等于主动放弃防注入能力，并承担重复解析开销。
MySQL 命令行里用 PREPARE / EXECUTE 要注意变量作用域
原生命令行调试时，PREPARE 定义的语句名只在当前连接内有效，且绑定参数必须是用户变量（以 @ 开头），不能直接传字面量。
-
PREPARE stmt FROM 'SELECT * FROM users WHERE id = ?'合法；但PREPARE stmt FROM 'SELECT * FROM users WHERE id = 123'就失去预处理意义 -
SET @uid = 100; EXECUTE stmt USING @uid正确；EXECUTE stmt USING 100会报错ERROR 1210 (HY000): Incorrect arguments to EXECUTE - 执行完记得
DEALLOCATE PREPARE stmt，否则连接空闲超时前该语句会一直占用服务端资源
PHP 中用 PDO::prepare 必须显式 bind 或 execute 带参数数组
PDO::prepare 返回的是语句对象，不调用 execute() 不会真正发送到 MySQL；且占位符类型和绑定方式直接影响类型安全。
- 问号占位符：必须传索引数组，顺序严格对应，
$stmt->execute([100, 'active']) - 命名参数：推荐用
:status这类形式，bindValue(':status', 'active', PDO::PARAM_STR)可控类型，避免自动类型转换引发隐式转换问题 - 别在
execute()里传空数组或null，会触发SQLSTATE[HY093]: Invalid parameter number
JDBC 和 C 语言驱动里要区分 client-side vs server-side prepare
MySQL 默认开启 server-side 预处理（5.7+），但 JDBC 驱动需显式配置 useServerPrepStmts=true，否则走的是客户端模拟——看似用了 PreparedStatement，实际每次仍发完整 SQL。
- JDBC 连接串加
?useServerPrepStmts=true&cachePrepStmts=true才真正复用执行计划 - C 语言用
mysql_stmt_prepare()时，MYSQL_STMT*句柄需配对mysql_stmt_close()，否则内存泄漏且连接数可能耗尽 - server-side 模式下，表名、列名、ORDER BY 子句等结构部分仍不能参数化，
SELECT * FROM ?直接报错ERROR 1064 (42000)
为什么 WHERE 条件里多个 IN 参数不能直接用 ? 占位
IN (?, ?, ?) 的问号个数必须编译期确定，动态长度的列表（如前端传来的 ID 数组）无法用单个预处理语句覆盖——这是预处理机制的硬限制，不是写法问题。
- 错误做法：
$ids = [1,2,3]; $stmt = $pdo->prepare('SELECT * FROM orders WHERE id IN (?)');—— 只能匹配一个值 - 可行方案：根据
$ids长度动态生成占位符串，'IN (' . str_repeat('?,', count($ids) - 1) . '?)'，再拼进 SQL 重新 prepare - 更稳妥方式：改用临时表或
FIND_IN_SET()（仅限小数据集），避免 SQL 拼接失控
最常被忽略的一点：预处理语句的“一次编译”优势，只有在**同一连接内多次执行相同模板**时才生效；如果每个 HTTP 请求都新建连接再 prepare，反而比普通查询更重——连接池配置和语句生命周期管理，比语法本身更关键。
