Question

如何利用准备好的陈述来提高绩效？我明白，如果我把它放在一个循环中，这样的东西可能会受益：

SELECT `Name` FROM `Hobbits` WHERE `ID` = :ID;

我已经读过使用预处理语句循环比循环使用更快，但是其他准备好的语句会略微降低性能。那么 - 这个循环有多大？

如果我在代码的开头运行一个复杂的SQL查询并在最后用一个不同的参数重复它 - 第二个查询会运行得更快吗？（我们为每个页面加载使用单个连接）。缓存查询是否有限制，所以我最好立即重复我的查询？

如何使用完全相同的参数执行两次整个脚本（重新加载页面或2个用户）？

Answer 1

为SQL服务器提供准备好的查询，该服务器解析它并且可能已经准备好执行计划。然后，您基本上会为这些已分配的资源分配一个id，并且可以通过填写语句中的空白来执行此预准备语句。您可以根据需要随时运行此语句，数据库不必重复解析和执行计划，可能提高速度。

只要你不丢弃该陈述，该陈述将“保持准备”多长时间就没有硬超时。它不是缓存，它是SQL服务器上的已分配资源。至少只要数据库驱动程序在SQL API中使用本机预处理语句。例如，PDO默认不，除非您将PDO::ATTR_EMULATE_PREPARES设置为false。

在脚本执行结束时，所有这些资源将始终被释放，它们不会在不同的页面加载中持续存在。除此之外，无论客户端脚本如何，SQL服务器都可以缓存查询及其结果一段时间。

Answer 2

准备缓存的mysql查询需要多长时间？

这实际上不是“缓存”。准备好的语句与脚本执行期间一样少。

如果我在代码的开头运行一个复杂的SQL查询并在最后用一个不同的参数重复它 - 第二个查询会运行得更快吗？

查询越复杂，您将看到的效果越少。坦率地说，准备好的语句只保存解析，而如果执行涉及临时或文件输出，或者表扫描 - 准备好的语句将不会加速它们。

另一方面，对于简单的主键查找，它不涉及复杂的查询解析，也不构建复杂的查询计划，对于没有人来说，这个好处可以忽略不计。

那么 - 这个循环有多大？

它获得的迭代次数越多 - 效益越大。但是，在一个理智的Web应用程序中，必须完全避免循环查询。

如何使用完全相同的参数执行两次整个脚本（重新加载页面或2个用户）？

正如我上面所说，准备好的声明根本没有任何好处。然而，经典的查询缓存很可能会触发。

如何利用准备好的陈述来提高绩效？

Noway。至少在Web服务PHP中没有。在一些长期运行的基于cli的脚本中 - 可能是。

但是，无论如何都应该使用准备好的语句，以便产生语法正确的查询。

Answer 3

仅供参考，

max_prepared_stmt_count系统变量控制服务器缓存的语句总数。（所有会话中准备好的陈述总数。）