PHP PDO 模拟预处理怎样影响参数行为

PDO::ATTR_EMULATE_PREPARES 改变的是预处理由 PDO 模拟还是优先交给驱动原生机制完成。它会影响重复命名占位符是否可用、SQL 错误暴露的阶段以及参数处理路径，但不会让占位符变成表名、列名或任意 SQL 片段。本例限定 PHP 8 与 PDO_MYSQL；我更倾向于先写不依赖模拟模式的参数，再决定连接选项，而不是用开关掩盖 SQL 写法的问题。

官方地址：https://www.php.net/manual/en/pdo.prepare.php。MySQL 驱动说明：https://www.php.net/manual/en/ref.pdo-mysql.php。

先确定驱动，再讨论是否关闭模拟

如果我要把一个已有的 MySQL 查询从模拟模式迁移到原生优先模式，首先会把 PDO_MYSQL、实际 PHP 版本和连接创建位置记清楚。这是方案选择，不是本文在某个线上项目取得的实测结论。PDO 是统一接口，但驱动支持并不相同，不能把 MySQL 的选项默认值套给所有数据库。

PDO_MYSQL 文档说明默认使用模拟预处理。显式设置 true 表示模拟；false 表示尝试使用原生预处理。官方 setAttribute 文档同时说明驱动无法成功预处理当前查询时存在模拟回退，因此我不会只凭 false 就声称每条 SQL 必然走服务器原生路径。该属性的驱动适用范围也应参照各自文档，而不是跨驱动盲目复制。

属性说明：https://www.php.net/manual/en/pdo.setattribute.php。新连接宜显式配置，框架项目则应在真实创建 PDO 的位置配置；临时创建另一个连接并不能改变原查询使用的连接。

把连接、SQL 模板和执行参数分开看

我的阅读顺序会分成三个对象：PDO 连接决定 ATTR_EMULATE_PREPARES；SQL 模板决定占位符布局；PDOStatement 承载绑定与执行。prepare 和 execute 都是调用点，但不代表模拟和原生模式在这两个调用点做同样的工作。

模拟模式下 prepare 不与数据库服务器通信，返回语句对象不等于 SQL 已被服务器认可。SQL 语法或对象相关错误可能等到 execute 才暴露。原生机制会涉及服务器预处理，但 execute 仍可能失败，例如执行时的数据或连接条件发生变化。所以迁移时应区分失败阶段，不能只捕获 execute，也不能认为 prepare 成功意味着后续一定成功。

先改重复占位符，再切换连接选项

最让我在方案比较中在意的不是 true 或 false 的拼写，而是 SQL 是否偷偷依赖了模拟模式。假设某条 SQL 写着 SELECT :value AS a, :value AS b，它把同一个命名占位符使用了两次。PDO 的规则要求为传入值安排独立标记；重复名称是模拟开启时的例外能力，不应当作跨模式契约。

更稳妥的迁移写法是 SELECT :left_value AS left_value, :right_value AS right_value，然后把同一个 PHP 值分别绑定到两个名字。业务上还是一个值，SQL 参数位置却明确分离。使用问号时同样需要为每个位置提供值，不能混用命名参数和问号参数。

这里的收益是减少模式依赖，代价是绑定代码略多。我会接受这一点重复，而不会为了省一个参数名把整个连接切回模拟。这个判断适合希望保持查询写法清晰的项目，并不代表所有遗留项目都能立刻无成本迁移。

整数参数显式绑定，不把数组自动当成整数契约

另一个容易混在开关讨论里的问题是参数类型。execute 接受参数数组，但官方文档规定该数组的值按 PDO::PARAM_STR 处理；bindValue 的第三个参数则可以显式指定 PDO::PARAM_INT 等类型。PHP 变量本身是整数，不意味着使用参数数组就表达了相同的绑定契约。

如果我要表达整数绑定，会先确保业务值确实是需要的整数，再使用 bindValue。PDO 类型标记不是业务输入检查器：不能期待 PDO::PARAM_INT 自动验证范围、格式或权限。输出数据的 PHP 类型还受驱动与取数选项等因素影响，不能只根据输出是字符串还是整数推断模拟开关。

下面的独立示例只执行常量 SELECT，不创建表、不写业务数据。运行者需要事先准备独立测试数据库、PDO_MYSQL 扩展以及三个环境变量；PDO_DEMO_DSN 的形式为 mysql:host=测试主机;dbname=测试库;charset=utf8mb4。环境变量不应在网页或日志里打印。本文没有运行数据库示例，输出只应由读者自己的环境产生。

 PDO::ERRMODE_EXCEPTION,
    PDO::ATTR_EMULATE_PREPARES => false,
    PDO::ATTR_DEFAULT_FETCH_MODE => PDO::FETCH_ASSOC,
]);

// 将相同业务值绑定到两个不同名字，不依赖模拟模式的重复名称能力。
$value = 17;
$stage = 'prepare';
try {
    $stmt = $pdo->prepare(
        'SELECT :left_value AS left_value, :right_value AS right_value'
    );
    $stage = 'bind';
    $stmt->bindValue(':left_value', $value, PDO::PARAM_INT);
    $stmt->bindValue(':right_value', $value, PDO::PARAM_INT);

    // 已显式绑定类型，就使用无参数 execute，避免重新传入参数数组。
    $stage = 'execute';
    $stmt->execute();
    var_export($stmt->fetch());
    $stmt->closeCursor();
} catch (PDOException $error) {
    // 只记录阶段和 SQLSTATE；不输出凭据或完整数据库错误消息。
    fwrite(STDERR, $stage . ' 失败，SQLSTATE=' . $error->getCode() . PHP_EOL);
    exit(1);
}

这段代码把 left_value 和 right_value 两个位置分别绑定为整数，在 execute 时不再传参数数组。查询仅用于确认两列都对应同一个业务值，不用于证明性能、完整驱动兼容性或每条 SQL 的原生执行路径。返回数组中的标量类型也不在本文作统一承诺。

类型与执行参数参考：https://www.php.net/manual/en/pdostatement.bindvalue.php；https://www.php.net/manual/en/pdostatement.execute.php。

哪些误区值得在切换前清掉

我不会为这个选项给出“所有项目都关闭才正确”的结论。新写的、原生机制支持的普通 MySQL 参数查询，可以明确选择 false，并避免重复参数名；已有系统应先确认代表性 SQL 和框架绑定方式，再变更连接配置。兼容性需要模拟时，也应明确记录原因，不能把它当作修复所有参数错误的万能按钮。

两种模式都应该使用参数绑定，而不是把用户值拼进 SQL。绑定仅表示完整的数据值，不会把动态表名、排序方向或 IN 列表自动变成安全结构；这些属于 SQL 构造层的独立设计问题。这里不展开它们的实现，避免让一个连接开关承担它不具备的职责。

遇到含特殊引号、注释或问号的 SQL，还要考虑版本与驱动解析规则。PHP 官方 prepare 文档区分 PHP 8.4 前的旧解析器与 8.4 起的驱动专用解析器，不能照搬老文章中的解析器描述到所有当前环境。简单 SQL 能执行不等于全部 SQL 都已适配。

几个实际选择问题

同一个值要用于两个条件怎么办？

使用两个不同参数名，分别绑定同一个 PHP 值。别为省一个名字让查询依赖模拟模式。

设置 false 后还要保留 execute 异常处理吗？

要。预处理和执行有不同失败条件，原生优先不等于执行必成功。

execute 数组里的 17 与 PARAM_INT 绑定等价吗？

不能把它们当成相同契约。数组值按 PARAM_STR 处理，明确整数绑定应使用 bindValue 的类型参数，再单独做好输入检查。

对我来说，值得先坚持的是参数位置独立、类型意图清晰、错误阶段可辨。满足这些条件后，ATTR_EMULATE_PREPARES 才是一项可解释的连接策略，而不是查询碰巧能跑的原因。