使用 PHP 时的 MySQL vs MySQLi [关闭]答案

【问题标题】：MySQL vs MySQLi when using PHP [closed]使用 PHP 时的 MySQL vs MySQLi [关闭]
【发布时间】：2010-10-07 15:10:36
【问题描述】：

MySQL 和 MySQLi 哪个更好？为什么？我应该使用哪个？

我的意思是更好，不仅仅是在性能方面，而是在任何其他相关功能方面。

【问题讨论】：

标签： php mysql mysqli

【解决方案1】：

如果您查看MySQL Improved Extension Overview，它应该会告诉您有关两者之间差异的所有信息。

主要有用的功能是：

面向对象的接口
支持准备好的语句
支持多个语句
支持交易
增强的调试功能
嵌入式服务器支持。

【讨论】：

是的，最好的是mysqli支持prepared statements
还需要注意的是，MySQLi 仅适用于 MySQL 5+。这已经不再重要了，但是当 MySQLi 出现时，MySQL 4 仍然是标准。这是扩展是分开的部分原因，旧的 MySQL 驱动程序保留在那里是出于兼容性目的。
值得注意的是，六年来情况发生了很大变化。 mysql_*() 现已弃用，将很快被删除。您不应该将它用于新代码。
我们应该选择哪个CPU和RAM更少？
见下面戈登的回答。不再支持旧的 mysql 扩展，所以无论如何你最好使用 mysqli 扩展。

【解决方案2】：

有一个手册页专门用于帮助在 mysql、mysqli 和 PDO 之间进行选择

PHP 团队推荐使用 mysqli 或 PDO_MySQL 进行新开发：

建议使用 mysqli 或 PDO_MySQL 扩展。不建议使用旧的mysql扩展进行新的开发。下面提供了详细的特征比较矩阵。所有三个扩展的整体性能被认为是大致相同的。尽管扩展的性能只占 PHP Web 请求总运行时间的一小部分。通常，影响低至 0.1%。

该页面还有一个比较扩展 API 的特征矩阵。 mysqli和mysql API的主要区别如下：

                               mysqli     mysql
Development Status             Active     Maintenance only
Lifecycle                      Active     Long Term Deprecation Announced*
Recommended                    Yes        No
OOP API                        Yes        No
Asynchronous Queries           Yes        No
Server-Side Prep. Statements   Yes        No
Stored Procedures              Yes        No
Multiple Statements            Yes        No
Transactions                   Yes        No
MySQL 5.1+ functionality       Yes        No

_{* http://news.php.net/php.internals/53799}

有一个额外的特征矩阵比较库（新的 mysqlnd 与 libmysql）在

http://www.php.net/manual/en/mysqlinfo.library.choosing.php

还有一篇非常详尽的博客文章在

http://blog.ulf-wendel.de/2012/php-mysql-why-to-upgrade-extmysql/

【讨论】：

【解决方案3】：

我已经放弃使用 mysqli。简直太不稳定了。我有过使用 mysqli 使 PHP 崩溃但使用 mysql 包工作得很好的查询。还有mysqli crashes on LONGTEXT columns。至少自 2005 年以来，此错误已以各种形式提出并且仍然存在。老实说，我很想使用准备好的语句，但 mysqli 不够可靠（而且似乎没有人费心修复它）。如果您真的想要准备好的语句，请使用 PDO。

【讨论】：

PDO 也不是很完美（我遇到过一些讨厌的核心转储），但至少它有更广泛的用户群，所以它可能是一个更安全的选择。
@troelskn，那么普通的mysql不是更好吗？
@Pacerier 考虑到它已被弃用，我会说不。总的来说，PDO 似乎已成为标准选择。
@troelskn，但弃用并不意味着它在未来的版本中不会出现。稳定性方面，普通的mysql不是更稳定吗？
此时（5.5）PHP如果使用它会主动发出警告：php.net/manual/en/migration55.deprecated.php

【解决方案4】：

对我来说，准备好的语句是必备的功能。更确切地说，参数绑定（仅适用于准备好的语句）。这是将字符串插入 SQL 命令的唯一真正明智的方法。我真的不相信“转义”功能。 DB 连接是二进制协议，为什么要使用 ASCII 限制的子协议作为参数？

【讨论】：

PDO 通常使用客户端准备好的语句，因此它们并没有真正在服务器上准备好——但这很好，因为它节省了服务器资源并且通常性能更好。准备好的语句“仿真”将始终正确地转义。
"always" 和 "escaping" 放在一起是危险的词。我不知道，也许这段代码完全没有错误；但是，当真正的二进制协议可用时，为什么还要麻烦呢？至于性能，可以进行基准测试。

【解决方案5】：

MySQLi 代表 MySQL 改进。它是 MySQL 绑定的面向对象的接口，使事情更易于使用。它还支持准备好的语句（这非常有用）。如果您使用的是 PHP 5，请使用 MySQLi。

【讨论】：

【解决方案6】：

更好的是PDO；它是一个不那么笨拙的界面，并且还提供了与 MySQLi 相同的功能。

使用准备好的语句是好的，因为它消除了 SQL 注入的可能性；使用服务器端准备好的语句是不好的，因为它会增加往返次数。

【讨论】：