在MySQL中使用SQL_CALC_FOUND_ROWS时，是否会影响查询的速度？

Question

前几天我在MySQL中找到了FOUND_ROWS()（here）函数，它是相应的SQL_CALC_FOUND_ROWS选项。后者看起来特别有用（而不是运行第二个查询来获取行数）。

我想知道通过向查询添加SQL_CALC_FOUND_ROWS会对速度产生什么影响？

我猜它会比运行第二个查询来计算行数要快得多，但它会有很大不同。此外，我发现限制查询以使其更快（例如，当你获得1000的前10行）。将SQL_CALC_FOUND_ROWS添加到具有较小限制的查询会导致查询运行得慢得多吗？

我知道我可以测试一下，但我想知道这里的一般做法。

Answer 1

要计算SQL_CALC_FOUND_ROWS，将执行查询，就好像没有设置LIMIT一样，但发送到客户端的结果集将遵循LIMIT。

---

更新：对于仅使用索引的COUNT（*）操作，SQL_CALC_FOUND_ROWS较慢（reference）。

Answer 2

当我参加2008年的MySQL大会时，一个会议的一部分专门用于这个 - SQL_CALC_FOUND_ROWS和单独SELECT之间的基准。

我相信结果是SQL_CALC_FOUND_ROWS没有任何好处 - 它不是更快，实际上它可能更慢。还有第三种方式。

此外，您并不总是需要此信息，因此我会使用额外的查询路径。

我会尝试找到幻灯片......

编辑：Hrm，谷歌告诉我，我实际上是从该会话中活跃起来的：http://beerpla.net/2008/04/16/mysql-conference-liveblogging-mysql-performance-under-a-microscope-the-tobias-and-jay-show-wednesday-200pm/。当内存失败时谷歌会赢。

Answer 3

我认为对于需要知道行数的查询会稍微快一些，但是对于您不需要知道的查询会产生开销和开销。

我能给出的最好的建议是在开发服务器上试用它并对差异进行基准测试。每个设置都不同。

Answer 4

我建议在开发应用程序时使用尽可能少的专有SQL扩展（或者根本不使用SQL查询）。单独执行查询是可移植的，实际上我认为MySql在获取实际信息方面不会比重新查询更好。顺便说一句。正如页面提到的那样，当在复制环境中使用时，命令也有一些缺点。