当在代码中作为准备好的语句运行时，MySQL 查询在 PHP 中运行缓慢，但通过直接 MySQL 查询运行速度很快

本篇文章主要是结合我之前面试的各种经历和实战开发中遇到的问题解决经验整理的，希望这篇《当在代码中作为准备好的语句运行时，MySQL 查询在 PHP 中运行缓慢，但通过直接 MySQL 查询运行速度很快》对你有很大帮助！欢迎收藏，分享给更多的需要的朋友学习~

我试图调试的一个 PHP 应用程序在一个更大的 MySQL 数据库上运行了几个设计糟糕的查询。

有几个页面真的很慢，结果发现这是因为一些查询。我开始一一检查每个查询，虽然它们很慢，但它们本身并没有那么慢。

经过进一步调试后发现，只有当应用程序将它们作为准备好的语句运行时，它们才会变慢。

• 如果我通过 MySQL 客户端手动运行查询，大约需要 300 毫秒。如果我通过My​​SQL客户端创建一个准备好的语句并设置参数并运行它，大约需要300毫秒。
• 如果我从 PHP (mysqli) 运行简单查询，大约需要 300 毫秒。
• 如果我像应用程序那样运行它（通过 mysqli）作为准备好的语句，则需要 100 秒。

我想可能是mysqli所以我用PDO尝试了一下，结果是一样的。尝试了不同的 PHP 版本（5.6、7.2、7.3）并得到相同的结果。

所以我给了最后一次机会，编写了一个小的 Go 脚本来测试，我得到了相同的结果，并且事情得到了改进。

现在，如果我从 MySQL 客户端、MySQL Workbench 或 PHPStorms 数据库客户端运行查询的预准备语句版本，速度会很快。如果我从代码运行查询，速度会非常快。

如果我能提供有关我应该注意什么、我应该在哪里继续调试的帮助，我们将不胜感激。

解决方案

事实证明，这是由略有不同的执行计划引起的。 MySQL似乎纯粹基于语句创建执行计划，不包括通过 mysqli 或 PDO 使用准备好的语句时的参数值，这是有道理的。然而，当它提供完整的查询时，在我们的例子中，它引入了对其中一个表的优化，这产生了巨大的差异。

其中一个表（包含 550 万行）在使用非准备语句运行时具有 Using join buffer (Block Nested Loop) Extra，而使用准备语句则没有。这似乎为我们带来了近 1000 倍的性能差异。

我仍然不确定为什么这通过 PHPStorm 或 CLI mysql 客户端没有问题，我最好的猜测是，MySQL 中的某些 API 期望在准备语句时执行计划完成，而其他 API 和CLI 客户端则不然。

理论要掌握，实操不能落！以上关于《当在代码中作为准备好的语句运行时，MySQL 查询在 PHP 中运行缓慢，但通过直接 MySQL 查询运行速度很快》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！