为什么不推荐使用 PHP 的 mysql_ 函数？ [复制]答案

【问题标题】：Why are PHP's mysql_ functions deprecated? [duplicate]为什么不推荐使用 PHP 的 mysql_ 函数？ [复制]
【发布时间】：2013-05-27 09:42:21
【问题描述】：

在我不久前停止使用这些功能时，在这里稍微玩一下 Devil's Advocate，但这个问题是真实的，可能对很多 SO 用户都很重要。

我们都知道以错误的方式使用mysql_ 函数可能非常危险，它可能使您的网站容易受到攻击等。但正确使用这些函数可以防止SQL 注入并且actually a fair bit faster 比新的PDO功能。

考虑到这一切，为什么不推荐使用 mysql_ 函数？

【问题讨论】：

也许.. 来不及问这个问题stackoverflow.com/questions/12859942/…
我问的是为什么它们被弃用以及我是否应该停止使用它们，而不是为什么我不应该使用它们。
最后一个问题在另一个主题中没有完全回答，所以：PHP 中的弃用意味着不被维护，只是因为遗留原因而留在那儿，最重要的是 将在未定义的未来版本中被删除。所以是的，你绝对应该停止使用它。
@NielsKeurentjes - 我们都知道，最终删除只会导致 mysql 函数被集中到一个库中，并且地球上的每个主机都继续将它编译到他们的 PHP 中，以免丢失遗留问题顾客。我在问为什么这些功能被弃用了。我找不到 PHP 团队的官方理由。
mysql_query 是对低级 C 绑定的一个非常薄的包装器，并且早在 SQL 注入问题等问题被认真对待之前就被引入了。它们是一种权宜之计，已成为拐杖和负担。如果历史是一个例子，供应商不会制作一个模块来支持这些功能，他们只会让 PHP 5.4 可用于遗留应用程序，就像 PHP 4 停留得很远，far 太长了。

标签： php mysql pdo mysqli

【解决方案1】：

弃用

据我所知，负责支持的是 Oracle 人员，只是拒绝再这样做了。这似乎是主要原因。

所有其他原因都只是愚蠢的借口。在同龄的 PHP 中有大量的扩展，愉快地运行起来。现代版本中的一些新功能并不是弃用旧功能的理由。 当然，图书馆本身没有安全问题，但图书馆用户。

这是否意味着我应该停止在我的网站中使用它们？

视情况而定。

对于遗留代码，我怀疑是否值得开始进行紧急重写。
至于全新的项目 - 答案很简单：

您不应该在应用程序代码中使用任何 API 调用，而只能在 DBAL 库中使用。

它不仅可以忽略整个驱动程序问题（因为您只需要重写一个相对较小的库代码即可更改驱动程序），而且它可以使您的代码显着缩短和清洁。

性能

说到性能差异，有一个有趣的事情要提。互联网确实充满的基准测试告诉您 X 比 Y 快 Z 倍。但是如何区分一个好的基准和一个坏的基准呢？一般情况下很难说。一般来说，在编写测试时，必须了解他们在做什么。不幸的是，大多数测试编写者都没有。

让我们在您的问题中选择一个链接。

通过在循环中包含连接代码，作者只是对连接时间进行了基准测试，而不是他打算测量的内容。 结果是完全可以预测的。
因为

已知连接是一项相对消耗资源的操作
mysql_connect() 从未真正重新连接（如果未明确告知），而是使用上次打开的连接。

因此，我们的 mysql ext 速度大大加快。难怪mysqli和PDO都要连接上千次，而mysql只需要连接一次。

从迭代代码中删除连接后，结果会发生巨大变化，显示完全无关紧要。

这个测试还有很多其他的陷阱，但是思路还是一样的：

切勿突然运行空闲基准测试。但是，只有在你有理由并且在真实环境中才进行任何基准测试。否则，您将测量任何有意义的数字以外的任何东西。

【讨论】：

mysql_*() 在后台使用 mysqlnd 驱动程序。所以这不是因为 libmysql 不受支持（因为它甚至不默认用于该扩展）...
好吧，这是愚蠢的假设。虽然我听说 mysql 的人参与了这场混乱。
是的，他们参与其中（并且是一些提出建议的人）...

【解决方案2】：

mysql 扩展是古老的，自 15 年前发布的 PHP 2.0 以来一直存在（！！）；这与现代 PHP 截然不同，后者试图摆脱过去的不良做法。 mysql 扩展是一个非常原始的、低级的 MySQL 连接器，它缺乏许多便利功能，因此很难以安全的方式正确应用；因此，这对新手不利。许多开发人员不了解 SQL 注入，而且 mysql API 非常脆弱，即使您知道它也很难阻止它。它充满了全局状态（例如隐式连接传递），这使得编写难以维护的代码变得容易。由于它很旧，在 PHP 核心级别上维护可能会非常困难。

mysqli 扩展更新很多，可以解决上述所有问题。 PDO 也是相当新的，它也解决了所有这些问题，而且还解决了更多问题。

由于这些原因* mysql 扩展将在未来某个时候被删除。它在鼎盛时期完成了它的工作，相当糟糕，但它做到了。时代在进步，最佳实践也在发展，应用程序变得更加复杂，需要更现代的 API。 mysql 即将退役，请继续使用它。

鉴于这一切，除了惯性之外，没有理由继续使用它。

* 这些是我的常识总结原因；完整的官方故事请看这里：https://wiki.php.net/rfc/mysql_deprecation

从该文档中选择引用如下：

文档团队正在讨论数据库安全情况，并教育用户远离常用的 ext/mysql 扩展是其中的一部分。

远离 ext/mysql 不仅关乎安全，还关乎安全可以访问 MySQL 数据库的所有功能。

ext/mysql 代码很难维护。它不是没有得到新的特征。保持最新以使用新版本的 libmysql 或 mysqlnd 版本是可行的，我们可能会花掉它时间更好。

【讨论】：

明确点：从ext/mysql 移动到ext/mysqli 或ext/pdo 与安全无关。事实上，根据 PHP 版本，PDO 可能不如ext/mysql 安全（特别是由于lack of ability to set the charset prior to 5.3.6）。因此，即使人们经常引用“安全原因”，这也是一个荒谬的答案。是的，Prepared Statements 更好。但这并不意味着 ext/mysql 在正确使用时不安全......
没错，mysql 本身并不是不安全； 安全地使用它更困难，或者说“不安全地使用它很容易”。当然，您总是可以使用任何 MySQL 库来打自己的脚。
当然。不争论这一点（或者它应该或不应该被弃用）。只是澄清这不是因为您无法保护ext/mysql...我听过一些非常杰出的开发人员说...
引用：由于这些原因，mysql 扩展将在未来的某个时候被删除 .....值得强调的是，这个“未来的某个时候”变得非常关闭，因为它发生在 PHP 5.5 中，现在处于测试阶段，将在几个月内完全发布。
@Spudley 它不会在 5.5 中被删除，他们只是会发出通知以鼓励人们远离它。删除可能不会再发布几个版本（即几年）

【解决方案3】：

由于它缺少当今人们所期待的功能，因此不再值得维护。由于 PHP 试图保持精简的 API (...)，您可以预期它最终会被删除。就像 IE7：在它“消失”之前，你不能指望使用它。您必须自己停止使用。

图片来自http://php.net/manual/en/mysqlinfo.api.choosing.php

【讨论】：

【解决方案4】：

为什么不推荐使用它们？

嗯，根本原因是 API 设计不佳。 mysqli 库是作为它的直接替代品而创建的，具有更好的 API 设计。

是的，库的内部代码存在问题，这意味着它需要被替换，但如果 API 一开始设计得更好，则无需编写 mysqli 库；改进后的代码可以简单地交换到现有的库中，我们作为开发人员可以继续使用现有的功能，甚至不需要知道内部发生了变化。

然而，事实并非如此。原始 API 确实存在一些严重的设计缺陷，这意味着当 PHP 开发人员想要改进时，会出现无法做到这一点的问题。

因此，对他们来说最好的做法是提供新的 API 并弃用旧的。

【讨论】：

如果这是事实（API 设计不佳），为什么 90% 的 PHP 标准库没有被弃用？ ;-)
@ircmaxell "如果要修复 PHP，请使用 [Python/Ruby/$otherRivalLanguage]"？ ;)
说到糟糕的设计，我会把手掌交给mysqli准备好的语句，这简直太疯狂了，几乎任何常见的操作都涉及到 call_user_func_array
完全同意！谁想到了那里的参考资料，就需要与...交谈...
@Spudley：很难回答的问题。太难了，以至于无法真正回答......