PDO vs MYSQLI，Prepared Statemens 和绑定参数

Posted 2023-02-24

【中文标题】PDO vs MYSQLI，Prepared Statemens 和绑定参数

【英文标题】：PDO vs MYSQLI, Prepared Statemens and Binding Parameters

【发布时间】：2013-05-21 13:36:57

【问题描述】：

我有这个问题要弄清楚。我阅读了一些文档和 cmets，但仍有一些内容不够清楚。

我知道 PDO 提供了更多驱动程序，如果您想更改数据库类型，这肯定是一个加分项。 正如在另一篇文章中所说，PDO 不提供真正的预处理语句，但 mysqli 提供，因此使用 MYSQLI 会更安全 基准看起来很相似，（我自己没有测试，但在网上查看了一些基准） 面向对象对我来说不是问题，因为 mysqli 正在迎头赶上。但是对程序 mysqli 与 PDO 进行基准测试会很好，因为程序应该稍微快一些。

但这是我的问题，对于准备好的语句，我们是否必须对我们在语句中使用的数据使用参数绑定？好的做法还是必须？我知道如果您多次运行相同的查询，准备好的语句在性能方面是很好的，但它足以保护查询本身吗？还是绑定参数是必须的？绑定参数究竟是什么以及它如何保护数据免受 sql 注入？如果您指出我们对我上述陈述的任何误解，我们将不胜感激。

【问题讨论】：

Should you use prepared statements for their escaping only?

说明 PDO 不支持本机准备语句的帖子是什么？它必须被删除或至少被否决

***.com/questions/134099/…, Quote=> “这里要意识到的重要一点是，PDO 默认情况下不会执行真正的准备好的语句。它模拟它们（对于 MySQL）。”，可能是我误解了.. .

关键字是“默认”。因此，它是可自定义的行为，但默认设置为最兼容的模式。

【参考方案1】：

总之，

绑定是必须的

，作为保护的基石，无论它是否被本机驱动程序支持。重要的是替代的想法。 在安全性和性能方面的差异

可以忽略不计

。

性能是最后要考虑的事情。

没有比其他 API 慢得多的 API。它不是可能导致任何性能问题的类或函数，而是数据操作或错误算法。优化您的查询，而不仅仅是调用它们的函数。 如果您打算使用原始的裸 API，那么 PDO 是唯一的选择。虽然包装在更高级别的类中，但 mysqli 似乎更适合 mysql。 mysqli 和 PDO 都缺少标识符和关键字的绑定。在这种情况下，必须实施基于

白名单

的保护。这是我的文章和现成的例子，Adding a field name to the SQL query dynamically

【讨论】：

如果我们正确使用prepared statements和bind parameters as应该的，那么我们仍然考虑使用这个safeMysql还是创建我们自己的类？我理解这有利于“方便，因为它使应用程序代码简短而有意义，没有无用的重复，使其更加干燥”，如他们的网站上所述。

因为“mysqli 和 PDO 都缺乏对重要文字的绑定”——例如标识符。尝试在 mysqli 或 PDO 中绑定字段名称并查看。 IN 语句也可能成为问题。 safeMysql 类的真正想法是为可能添加到查询中的 everything 提供一个占位符，而不仅仅是 mysqli 那样的 1 或 2 个数据类型。