在我们的地方,我们使用mysqli和PDO来处理准备好的语句和事务支持。有些项目使用其中一种,有些使用另一种。我们几乎不可能迁移到另一个RDBMS。

我更喜欢PDO,原因只有一个,它允许对预处理语句使用命名参数,而据我所知mysqli不允许。

当我们合并我们的项目只使用一种方法时,选择其中一种作为标准是否还有其他优点和缺点?


当前回答

编辑回答。

在对这两个api都有一些使用经验之后,我想说有两个阻塞级别的特性使mysqli无法与本机准备好的语句一起使用。 他们已经在两个优秀(但被低估了)的答案中提到过:

将值绑定到任意数量的占位符 仅以数组形式返回数据

(在这个答案中也提到了)

出于某种原因,mysqli两者都失败了。 现在它对第二个函数(get_result)有了一些改进,但它只能在mysqlnd安装上工作,这意味着你不能在你的脚本中依赖这个函数。

然而,直到今天,它还没有按值绑定。

所以,只有一个选择:PDO

所有其他的原因,比如

命名占位符(这种语法糖被高估了) 不同的数据库支持(实际上没有人使用过) 获取到对象(只是无用的语法糖) 速度差(没有)

都不重要。

同时,这两个api都缺乏一些真正重要的特性,比如

标识符占位符 复杂数据类型的占位符,使动态绑定不那么费力 更短的应用程序代码。

因此,为了满足现实生活的需要,人们必须创建自己的抽象库,基于这些api之一,实现手动解析的占位符。在这种情况下,我更喜欢mysqli,因为它具有较低的抽象级别。

其他回答

将应用程序从一个数据库移动到另一个数据库并不常见,但您迟早会发现自己正在使用不同的RDBMS处理另一个项目。如果你在家里使用PDO,那么在这一点上至少会少学一件事。

除此之外,我发现PDO API更直观一些,而且感觉更真正面向对象。mysqli感觉它只是一个被物化的过程API,如果你明白我的意思的话。简而言之,我发现PDO更容易使用,但这当然是主观的。

在我的基准测试脚本中,每个方法都要测试10000次,并打印每个方法总时间的差值。你应该在你自己的配置上这样做,我相信结果会有所不同!

以下是我的结果:

"SELECT NULL" -> PGO()更快~ 0.35秒 "SHOW TABLE STATUS" -> mysqli()加快~ 2.3秒 "SELECT * FROM users" -> mysqli()快了~ 33秒

注意:通过使用->fetch_row() for mysqli,列名不会添加到数组中,我没有找到在PGO中这样做的方法。但即使我使用->fetch_array(), mysqli略慢,但仍然比PGO快(除了SELECT NULL)。

如果你的站点/web应用真的变得很简单,PDO将使它更容易扩展,因为你可以每天设置主连接和从连接,在数据库中分配负载,加上PHP正朝着PDO作为标准的方向发展。

PDO信息

扩展Web应用程序

关于PDO的另一个值得注意的(好的)区别是,它的PDO::quote()方法自动添加外围引号,而mysqli::real_escape_string()(和类似的)不会:

PDO::quote()在输入字符串周围放置引号(如果需要)和 使用引号转义输入字符串中的特殊字符 适合底层驱动程序的样式。

编辑回答。

在对这两个api都有一些使用经验之后,我想说有两个阻塞级别的特性使mysqli无法与本机准备好的语句一起使用。 他们已经在两个优秀(但被低估了)的答案中提到过:

将值绑定到任意数量的占位符 仅以数组形式返回数据

(在这个答案中也提到了)

出于某种原因,mysqli两者都失败了。 现在它对第二个函数(get_result)有了一些改进,但它只能在mysqlnd安装上工作,这意味着你不能在你的脚本中依赖这个函数。

然而,直到今天,它还没有按值绑定。

所以,只有一个选择:PDO

所有其他的原因,比如

命名占位符(这种语法糖被高估了) 不同的数据库支持(实际上没有人使用过) 获取到对象(只是无用的语法糖) 速度差(没有)

都不重要。

同时,这两个api都缺乏一些真正重要的特性,比如

标识符占位符 复杂数据类型的占位符,使动态绑定不那么费力 更短的应用程序代码。

因此,为了满足现实生活的需要,人们必须创建自己的抽象库,基于这些api之一,实现手动解析的占位符。在这种情况下,我更喜欢mysqli,因为它具有较低的抽象级别。