当一条 SQL 语句需要被反复执行、只是参数不同时，如果每次都让数据库重新解析语法、生成执行计划，无疑是一种浪费。MySQL 提供的准备好的语句机制，允许我们先把语句模板编译好，再多次传入不同的参数执行，既提升了性能，又天然规避了 SQL 注入风险。本文将从 SQL 层面的用法讲到编程语言层面的实践，把这个特性彻底讲清楚。
一、什么是准备好的语句，它解决了什么问题
准备好的语句，英文叫 Prepared Statement，核心思想是“一次编译，多次执行”。正常情况下，MySQL 收到一条 SQL 后要经历词法分析、语法分析、语义检查、优化器生成执行计划这几个阶段，最后才真正执行。如果同一条语句只是 WHERE 条件里的值在变，前面这些准备工作其实完全可以复用。
使用准备好的语句后，语句的结构在 PREPARE 阶段就确定下来了，参数位置用问号占位，执行时只需要把具体的值“填”进去。由于语句结构已经固定，参数值永远只会被当作数据对待，不会被当作 SQL 语法的一部分解析，这就是它能防 SQL 注入的根本原因。比如攻击者传入一个包含 ' OR '1'='1 的字符串，在预编译机制下它只是一个普通的字符串值，不会改变查询逻辑。
需要注意的是，MySQL 的预编译分为两种形态：一种是 SQL 层面的 PREPARE 语句，直接在客户端敲命令就能用；另一种是编程语言驱动层的预编译，比如 JDBC 的 PreparedStatement、PHP 的 PDO 预处理。前者适合临时操作和存储过程，后者才是日常开发的主力。
二、SQL 层面的基本用法：PREPARE、EXECUTE、DEALLOCATE
在 MySQL 命令行中，预编译语句的使用遵循固定的三步流程。先用 PREPARE 准备语句，再用 EXECUTE 执行，最后用 DEALLOCATE 释放。下面是一个完整示例：
-- 第一步：准备语句，参数用 ? 占位 PREPARE stmt FROM 'SELECT id, name, age FROM users WHERE age > ? AND city = ?'; -- 第二步：定义变量并执行 SET @min_age = 18; SET @city = '北京'; EXECUTE stmt USING @min_age, @city; -- 换一组参数再执行一次，无需重新 PREPARE SET @min_age = 30; SET @city = '上海'; EXECUTE stmt USING @min_age, @city; -- 第三步：用完释放资源 DEALLOCATE PREPARE stmt;
这段代码里有几个细节值得注意。首先，USING 后面的变量必须是用户变量（以 @ 开头），不能是局部变量或字面量，这一点和存储过程里的写法不同。其次，占位符的个数必须和 USING 提供的变量个数一致，顺序也要一一对应，多了少了都会直接报错。
PREPARE 的语句来源还可以是一个变量，这在需要动态拼接表名或列名的场景特别有用。比如先拼好一条完整的 SQL 字符串存到变量里，再交给 PREPARE 处理。这种“动态 SQL”技术在存储过程中很常见，因为存储过程原生不支持用变量直接替换表名。
SET @table_name = CONCAT('orders_2024_01');
SET @sql = CONCAT('SELECT COUNT(*) FROM ', @table_name, ' WHERE status = ?');
PREPARE stmt FROM @sql;
SET @s = 'paid';
EXECUTE stmt USING @s;
DEALLOCATE PREPARE stmt;
这个例子揭示了一个关键限制：占位符只能出现在值的位置，可以替换数字、字符串，但不能用来替换表名、列名、SQL 关键字。想让这些部分动态化，就只能通过字符串拼接加 PREPARE 的方式实现。而拼接就带来了注入风险，所以动态部分的来源必须严格校验，比如用白名单限制可用的表名。
三、在编程语言中使用预编译语句
实际项目里，我们更多通过数据库驱动来使用预编译。以 PHP 的 PDO 为例，写法非常直观：
$pdo = new PDO('mysql:host=127.0.0.1;dbname=test;charset=utf8mb4', 'root', 'password');
// 准备并执行，参数用问号占位
$stmt = $pdo->prepare('SELECT id, name FROM users WHERE email = ? AND status = ?');
$stmt->execute(['user@ipipp.com', 1]);
$rows = $stmt->fetchAll(PDO::FETCH_ASSOC);
// 命名占位符写法
$stmt = $pdo->prepare('UPDATE users SET last_login = NOW() WHERE id = :id');
$stmt->execute(['id' => 42]);
看到这里有人可能会问：PDO 默认并没有真正使用 MySQL 服务端的预编译，而是驱动在客户端模拟了参数替换。这叫模拟预编译（emulated prepares）。可以通过 PDO::ATTR_EMULATE_PREPARES => false 关闭模拟，让请求真正走服务端预编译通道。两种模式各有取舍：模拟模式支持更多语法、可以少一次网络往返；服务端模式防注入更可靠，字符集处理也更严谨。生产环境建议关闭模拟，除非有明确的兼容性需求。
Java 的 JDBC 则是天然的服务端预编译，PreparedStatement 的用法和 PDO 类似，占位符一律用问号，通过 setInt、setString 等方法按位置绑定参数。无论哪种语言，核心原则一致：用户输入永远通过参数绑定传递，绝不拼接到 SQL 字符串里。
四、性能与常见坑点
从性能角度看，预编译的收益主要体现在两类场景：一是同构语句高频执行，比如批量插入上千条记录；二是复杂查询的编译开销本身较大，复用执行计划省下的时间可观。MySQL 服务端会维护一个预编译语句缓存，相同结构的语句再次到来时可以直接命中。但要注意，如果业务里每次的 SQL 结构都略有差异（比如动态拼接了 IN 列表），缓存命中率会很低，预编译反而多了准备阶段的开销。
使用过程中有几个常见的坑需要避开。第一，每个会话的预编译语句是独立隔离的，会话结束自动释放，但长连接下大量 PREPARE 而不 DEALLOCATE，会占用资源，可以通过 max_prepared_stmt_count 变量看到全局上限。第二，不是所有语句都能预编译，比如 LOCK TABLES、SET 等就不支持，遇到报错时先查一下语句类型。第三，使用 SQL 层 PREPARE 时，LIKE 模糊查询的通配符不能整体作为参数绑定后丢失，正确做法是把通配符放进值里：
-- 正确：通配符包含在变量值中 SET @kw = '%张%'; PREPARE stmt FROM 'SELECT name FROM users WHERE name LIKE ?'; EXECUTE stmt USING @kw; DEALLOCATE PREPARE stmt;
掌握这些细节后，准备好的语句就能同时为你的系统带来性能和安全性两方面的提升。简单总结：值用占位符，结构要固定，动态拼接需谨慎，用完记得释放。这套原则贯穿 SQL 层和驱动层，是写好数据库访问代码的基本功。
MySQL准备好的语句PREPARE语句SQL注入防范修改时间：2026-09-07 10:12:45