PHP PDO 怎样区分预处理模拟和原生预处理

PHP PDO 里最容易混淆的一点是：调用了 prepare()，不等于数据库一定收到了原生预处理语句。判断当前连接采用哪种模式，先看 PDO::ATTR_EMULATE_PREPARES：设为 true 时由 PDO 模拟，设为 false 时尝试使用驱动的原生预处理；驱动无法原生准备某条语句时，仍可能回退到模拟路径。

官方地址：https://www.php.net/manual/en/pdo.prepare.php

先把两个模式放进同一张判断表

模拟预处理时，PDO 在客户端处理占位符，不需要在 prepare() 调用时把语句交给数据库服务器检查；原生预处理则要求驱动和服务器协作完成准备。两者都可以使用参数绑定来避免把输入直接拼进 SQL，但语句检查的位置、占位符限制和失败时机不同。

用属性显式设置，再读取当前连接的值

最稳妥的做法是在创建连接时把模式写进 options，并在需要诊断或启动记录时读取一次实际值。这样能把部署环境中的默认差异变成可观察信息：

 PDO::ERRMODE_EXCEPTION,
        // false 表示请求驱动使用原生预处理。
        PDO::ATTR_EMULATE_PREPARES => false,
    ]
);

// 读取实际连接属性，不猜测服务器或驱动的默认值。
$emulated = $pdo->getAttribute(PDO::ATTR_EMULATE_PREPARES);
if ($emulated === true) {
    echo "当前连接：模拟预处理\n";
} elseif ($emulated === false) {
    echo "当前连接：请求原生预处理\n";
} else {
    // 某些驱动返回值的表现可能不同，保留原值便于排查。
    var_export($emulated);
}

这段代码中的“请求原生”是有意保留的措辞：把属性设为 false 代表尝试原生路径，并不等于每条语句都已经在服务器端成功准备。对于确实需要兼容的驱动，应把读取结果、驱动名和异常信息一起写入诊断日志，而不是只记录一个布尔值。

为什么同一段 prepare 代码会出现不同表现

当模拟模式开启时，prepare() 可能只完成客户端侧的模板处理，因此 SQL 中较早暴露的语法问题不一定在这一步出现。关闭模拟后，驱动会把准备动作交给服务器，服务器不接受的语句可能更早返回异常。

prepare($sql);

// 用明确的参数类型传递数据，避免把输入拼进 SQL 字符串。
$stmt->execute(['id' => 42]);
$row = $stmt->fetch(PDO::FETCH_ASSOC);

// fetch 可能返回 false，调用方要处理“没有匹配行”的正常分支。
if ($row === false) {
    echo "没有找到用户\n";
} else {
    echo $row['email'] . "\n";
}

不要把占位符放在表名、列名或 SQL 关键字位置，也不要给占位符再手动加引号。模拟模式不能把任意 SQL 片段变成可绑定参数；原生模式还要额外服从目标驱动的占位符能力。

用三个可记录指标比较，而不是凭感觉切换

如果切换模式的原因是性能或稳定性，建议先建立同一组 SQL 的基线。这里的“指标”不是文章里可以直接套用的固定数字，而是每个项目都应该在自己的 PHP 版本、驱动和数据库上测量的观察点。

prepare('SELECT id FROM users WHERE email = :email');
$stmt->execute(['email' => 'demo@example.com']);
$stmt->fetch(PDO::FETCH_ASSOC);
$elapsedNs = hrtime(true) - $start;

// 把纳秒转换为毫秒，日志中同时记录模式和 SQL 模板标识。
$mode = $pdo->getAttribute(PDO::ATTR_EMULATE_PREPARES) ? 'emulated' : 'native-requested';
printf("mode=%s elapsed_ms=%.3f\n", $mode, $elapsedNs / 1_000_000);

单次计时同时包含 PHP、网络、服务器和结果读取成本，不能把它直接解释成“模拟解析器比原生更快”。如果要下结论，应固定连接复用、数据分布、缓存状态和批量大小，并把异常率与尾延迟一起看。

PDO_MYSQL 的默认值不是部署契约

PHP 官方的 PDO_MYSQL 手册写明，该驱动默认使用模拟预处理。默认值能帮助解释“本机没报错、切到另一套环境却提前报错”的现象，但生产代码不应依赖默认值：连接 options 应明确表达团队选择，启动日志也应记录实际读取结果。

如果某条 SQL 在原生模式下无法准备，而业务又必须使用该驱动能力范围之外的写法，可以把模拟模式作为有意识的兼容方案；同时保留 SQL 模板约束、参数绑定和回归用例。若目标是让服务器检查语句并尽早暴露错误，则应优先使用原生请求，并逐条修正不兼容的占位符写法。

最后用这份清单决定是否切换

• 连接 options 是否显式写了 PDO::ATTR_EMULATE_PREPARES？
• 启动或诊断日志是否读取了当前连接的实际属性，而不是只记录配置文件？
• 测试是否覆盖 prepare 阶段和 execute 阶段的异常？
• SQL 是否只把完整数据值交给占位符，动态表名和列名是否采用白名单？
• 性能结论是否来自固定条件下的多轮测量，并同时观察异常率和尾延迟？

常见问题

把 ATTR_EMULATE_PREPARES 设为 false 就一定是原生预处理吗？

不一定。false 表示请求原生预处理；驱动不支持或当前语句无法原生准备时，PDO 可能回退到模拟路径，具体要结合驱动文档和实际异常记录判断。

模拟预处理是不是就等于没有参数安全性？

不能这样简单判断。参数化仍然是基本做法，但模拟路径有自己的解析边界，不能把用户输入拼成 SQL，也不能用占位符替代标识符或 SQL 结构。

应该为了性能默认打开模拟模式吗？

不要凭经验决定。先在目标环境建立基线，比较重复查询耗时、尾延迟、异常率和兼容性，再根据实际约束选择并显式配置。