当我不久前停止使用这些函数时，在这里稍微扮演一个魔鬼拥护者的角色，但这个问题是真实的，可能对很多这样的用户很重要。
我们都知道，以错误的方式使用mysql_函数可能非常危险，它会使您的网站易受攻击等，但正确使用这些函数可以防止SQL注入，实际上比更新的pdo函数快一点。
考虑到所有这些，为什么不推荐使用mysql_函数？
- 也许。。问这个问题太晚了stackoverflow.com/questions/12859942/&hellip；
- 我在问他们为什么被否决，我是否应该停止使用他们，而不是为什么我不应该使用他们。
- 为什么不在PHP中使用mysql_u*函数呢？
- 最后一个问题在另一个主题中没有完全回答，所以：php中的deprecation意味着没有被维护，只是因为遗留的原因留在那里，而且在未来的未定义版本中，大部分都将被删除。所以是的，你应该停止使用它。
- @Nielskeurentjes——我们都知道最终的删除只会导致mysql函数被集中到一个库中，而地球上的每一个主机都会继续将其编译到自己的PHP中，以免失去原有的客户。我在问为什么不推荐这些功能。我找不到PHP团队的官方理由。
- @我不会屏息以待在php6发生这种事。虽然5分支机构肯定会永远支持它，但切换到6分支机构极有可能从根本上放弃它，我怀疑在宿主中是否会普遍支持主要版本的自定义补丁，这也会破坏许多其他代码。
- mysql_query是围绕低级C绑定的一个非常薄的包装器，早在认真对待SQL注入问题之前就引入了它。它们是一种权宜之计，已成为一种拐杖和责任。如果历史就是一个例子，那么提供者就不会创建一个模块来支持这些函数，他们只会让php 5.4可以用于遗留应用程序，就像php 4停留的时间太长太久一样。
- 投票让你重新开始那个问题。我知道底层的mysql客户机库已经过时了。由于php userland中的mysql_*是针对php的C库(libmysqlclient)的绑定，因此它也过时了。如果您有一个更新的PHP版本，请确保您的mysqlnd在后台运行，那么mysql_*将使用该客户机库。php.net/mysqlinfo.library.选择
- 事实上，正如Rasmus经常说的那样，整个PHP是"围绕低级C绑定的非常薄的包装器"。没有人会因为这个原因而贬低它。
- 我也认为这个问题很有用。能够指出数不清的用户为什么不推荐使用MySQL，而不是指出他们为什么不推荐使用MySQL。假设的副本有一个简短的答案，有充分的理由反对使用MySQL，还有一个巨大的答案，没有人会读，所以它不是一个有用的副本。
- @你的常识：当然，只是为了过时，它会被弃用。如果用这种方式编译PHP，仍然可以使用libmysqlclient找到arround。但是，不要期望非常薄的包装层上有任何进展，因为mysql_*非常薄的包装层已被弃用，不再受到关注。
- @Niels还不清楚什么时候会出现php 6，它会是什么样子。现在，php开发人员致力于5.x分支的年度发布周期，看到5.7(即2015年)中删除不推荐使用的API，我不会感到惊讶。
- 即使这不是一个"复制品"，它也应该作为主观封闭。这不是个好问题。你问"我应该停止使用它们吗？"好吧，这是一个观点。这会引起争论。大多数人都会说"见不到"，但如果有人说"他们几乎可以使用，忽略所有其他人"。事实上，如果没有某种程度的主观性，回答这个问题是不可能的，它打开了许多猜测和争论的大门。我的意见是应该这样关闭…
- @不过，ircmaxell的"为什么不推荐使用"是一个相当值得回答的问题。删除问题的另一部分会有帮助吗？
- @死亡：我认为这对主观方面肯定有帮助。但我仍然不认为这是一个很好的问题，所以格式。不过，删除第二个问题将是朝着正确方向迈出的一步…
- PDO可以像mysql或mysqli一样容易被使用。它们是工具。在右手中，他们可以做出一幅美丽的画，或者建造一个奇妙的结构。如果用错了手，他们会把用户的脚炸掉，或者把邻居的脚炸掉。这不是工具的问题，而是用户的问题。
- 想想这个关于折旧的讨论量，这个工具显示它不是简单的"为什么它比X更差？"问题。在这些情况下，调解人应该站在公开讨论的立场上犯错。
- @死亡-同意你的观点，我应该把这个保留到一个问题上。但现在应该重新打开。
mysql扩展是很古老的，从15年前发布的php 2.0开始就存在了。！)；这是一个明显不同于现代PHP的野兽，后者试图摆脱过去的坏习惯。MySQL扩展是一个非常原始的、低级的MySQL连接器，它缺乏许多便利功能，因此很难以安全的方式正确应用；因此，它对Noobs不利。许多开发人员不理解SQL注入，并且mysql api非常脆弱，即使您知道它，也很难防止它发生。它充满了全局状态(例如隐式连接传递)，这使得编写难以维护的代码变得容易。由于它是旧的，所以很难在PHP核心级别维护它。
mysqli扩展是一个更新的版本，可以解决上述所有问题。PDO也是一个相当新的工具，可以解决所有这些问题，还有更多的问题。
由于这些原因*MySQL扩展将在将来某个时候被删除。它在全盛时期做得相当糟糕，但它做到了。随着时间的推移，最佳实践不断发展，应用程序变得更加复杂，需要更现代的API。MySQL已经退休了，继续生活吧。
考虑到所有这些，除了惯性，没有理由继续使用它。
*这些是我的常识总结的原因；对于整个官方故事，请看这里：https://wiki.php.net/rfc/mysql_deprecation
该文档中的选项引用如下：
The documentation team is discussing the database security situation,
and educating users to move away from the commonly used ext/mysql
extension is part of this.
Moving away from ext/mysql is not only about security but also about
having access to all features of the MySQL database.
ext/mysql is hard to maintain code. It is not not getting new
features. Keeping it up to date for working with new versions of
libmysql or mysqlnd versions is work, we probably could spend that
time better.
- 明确点：从ext/mysql到ext/mysqli或ext/pdo的移动与安全无关。事实上，根据php版本的不同，PDO可能比ext/mysql的安全性低(特别是由于缺乏在5.3.6之前设置字符集的能力)。所以，尽管人们经常引用"安全原因"，但这是一个BS答案。是的，准备好的陈述更好。但这并不意味着正确使用ext/mysql并不安全……
- 的确，MySQL本身并不不安全；更难安全地使用它，或者说"很容易不安全地使用它"。当然，你也可以用任何一个MySQL库来攻击自己。
- 一定地。没有争论这一点(或者它应该或不应该被否决)。只是澄清这不是因为你不能保护好ext/mysql…我听过一些著名的开发者说…
- 引用：由于这些原因，MySQL扩展将在将来某个时候被删除…..值得强调的是，"将来的某个时候"已经非常接近了，因为它发生在php 5.5中，现在是beta版本，几个月后就会完全发布。
- @spudley在5.5中没有被移除，他们只是让它发出通知，鼓励人们远离它。删除可能不会再进行两次发布(即几年)
- @imsop-最近的历史表明，在正式否决PHP功能后，将在下一个版本中删除这些功能。但是，是的，有一点。：)
贬低
据我所知，这是甲骨文的人负责的支持，只是拒绝这样做了。这似乎是主要原因。
所有其他的原因都只是愚蠢的借口。在同一个时代的PHP中有大量的扩展，可以很高兴地启动和运行。现代版本中的一些新功能并不是贬低旧功能的原因。当然，图书馆本身并没有安全问题，而是图书馆用户。
does this mean I should cease to use them in my sites?
这要看情况而定。
- 对于遗留代码，我怀疑它是否值得紧急重写。
- 对于全新的项目，答案相当简单：
您不应该在应用程序代码中使用任何API调用，而应该只在dbal库中使用。
它不仅使整个驱动程序问题可以忽略不计(因为您只需要重写一个相对较小的库代码来更改驱动程序)，而且还可以使您的代码大大缩短和更清晰。
性能
说到性能差异，有一件有趣的事要提。互联网上确实充满了基准，告诉你x比y快z倍。但如何区分一个好的基准和一个坏的基准呢？总的来说很难说清楚。一般来说，在编写测试时，必须理解他们在做什么。不幸的是，大多数测试作者没有。
让我们把你的问题联系起来。
通过在循环中包含连接代码，作者只需要基准化连接时间，而不是他打算测量的时间。结果是可以预测的。因为
- 众所周知，连接是一个相对消耗资源的操作
- mysql_connect()从未实际重新连接(如果没有明确告知)，而是使用上次打开的连接。
因此，我们的mysql ext速度非常快。怪不得，因为mysqli和pdo都必须连接上千次，而mysql只能连接一次。
从迭代代码中删除connect后，结果会发生显著变化，显示出完全不重要。
这项测试还有许多其他的陷阱，但其想法仍然是一样的：
永远不要把闲置的基准点从任何地方跑出来。但是，始终只在您有理由和在实际环境中进行基准测试的情况下才进行基准测试。否则，除了有意义的数字，你什么都可以测量。
- mysql_*()在引擎盖下使用mysqlnd驱动程序。所以这不是因为libmysql不受支持(因为它在默认情况下甚至没有用于扩展名)。
- 好吧，这是一个愚蠢的假设。尽管我听说MySQL的人都卷入了这场混乱。
- 是的，他们参与其中(其中一些人提出了建议)
为什么不推荐？
好吧，根本原因是API设计得不好。mysqli库是作为它的直接替代品而创建的，具有更好的API设计。
是的，库的内部代码存在问题，这意味着需要替换它，但是如果API在第一时间得到了更好的设计，则不需要编写mysqli库；改进后的代码可以简单地交换到现有库中，我们作为开发人员可以继续使用exiSting的功能甚至不需要知道内部情况发生了变化。
但事实并非如此。最初的API确实存在一些关键的设计缺陷，这意味着当PHP开发人员想要改进时，会出现一些问题，这意味着他们无法做到这一点。
因此，对他们来说，最好的做法是提供一个新的API，并废除旧的API。
- 如果这是事实(API设计得不好)，为什么90%的php-std-lib不推荐使用？；-)
- @ircmaxell"如果要修复php，请使用"？；)
- 说到糟糕的设计，我会将手掌交给mysqli准备好的语句，这简直是疯狂的，涉及到为几乎所有普通操作调用_user_func_array
- 完全同意！不管是谁想到了推荐信，都需要和…
- @Ircmaxell-好吧，假设…假设最初的ext-mysql api从第一天起就和我们现在所知道的ext-mysqli完全相同；所以，例如连接变量不是可选的，等等。现在，当他们决定写mysqli时，fast fwd to：内部有一些缺陷，需要添加一些东西(准备语句)，但是核心api是"完美的"(正如他们当时看到的那样)。)问题：考虑到这一点，他们是否还会创建ext-mysqli，或者只是简单地重写ext-mysql的内部结构？
- @斯普德利：很难回答的问题。太难了，这不是真正的责任…
- @spudley假设只有内部是复杂的，但是完全可以替换它们，而完全不需要更改面向外部的API，从而破坏现有的代码…答案似乎很明显。低级C连接器就是以这种方式替换的(mysqlnd)。
- @是的，我很感激！：-)这只是假设。我的猜测是他们会重写内部结构并保留API；这就是我的答案的核心。
因为它现在缺少人们简单期望的功能，所以不值得维护。当PHP试图保持一个瘦的API(…)时，您可以期望它最终被删除。就像IE7一样：在它"消失"之前，你不能指望使用它。你必须自己停止使用。
图片来自http://php.net/manual/en/mysqlinfo.api.choosing.php
