Python 理解MySQL游标类型

MySQL版本：5.5.37-0ubuntu0.14.04.1

我目前正在编写一个python脚本，它利用大量MySQL表和查询从存储在表中的反向索引获取结果

我注意到，在执行查询时，在MySQLdb python模块中选择正确的游标类型对性能有很大影响，我想知道是否有人可以解释或提供可靠的资源来解释何时使用哪个游标

例如，使用SSCursor执行此查询40次需要7秒：

SELECT Pages.PageID,
       Pages.PageName,
       Counter AS TermFreq,
       Pages.Length,
       (Counter / LOG(Length)) AS Weight
FROM Pages
INNER JOIN TermOccurrences ON TermOccurrences.PageID = Pages.PageID
INNER JOIN Terms ON TermOccurrences.TermID = Terms.TermID
WHERE TermName = %s
ORDER BY Weight DESC
LIMIT 20;

使用默认光标运行同一查询40次需要0.004秒

但是，删除权重（计数器/日志（长度））的计算会使用SSCursor再次快速执行此查询

我之所以使用SSCursor，是因为它在许多其他查询中被证明具有非常优异的性能，然后突然变得非常慢。当它执行得如此之快时，更改回默认光标让我感到惊讶

编辑： 还有一些例子

使用默认光标运行以下操作40次需要约3秒：

SELECT COUNT(*)
FROM Pages
INNER JOIN TermOccurrences ON TermOccurrences.PageID = Pages.PageID
INNER JOIN Terms ON TermOccurrences.TermID = Terms.TermID
WHERE TermName = %s AND Counter > 2

使用SSCursor运行它大约需要0.002秒。

提到标准游标类使用的是

mysql\u store\u result（）

，而SSCursor使用的是

mysql\u use\u result（）

“对于后者，必须确保在执行另一个查询之前读取了所有行”

因此，它是关于mysql\u存储\u结果（）vs

mysql\u使用\u结果（）

提到

mysql\u use\u result（）

会启动结果集检索，而不会像mysql\u store\u result（）那样将结果集实际读入客户端。因此，必须通过调用

mysql\u fetch\u row（）

来单独检索每一行，当然，在处理大型表时，这会增加很多

在MySQLdb文档中也有：

SSCursor：一个“服务器端”游标。喜欢游标，但使用 CursorUsersUltMixin。仅当您正在处理潜在的 大型结果集

因此，如果您的结果集太大，无法同时移动到您的客户机中，

SSCursor

主要是好的

另见以下问题：

---

请注意，

LIMIT 20

查询永远不会有那么大。你可能得检查一下你的钥匙。为了更好地了解这可能需要7秒钟的原因，最好在一个问题中也包括db模式，这可能更重要。

事实上，这是一个很好的问题。浏览一下pythonmysql的源代码，我找不到任何能让它变得如此缓慢的东西。。。我所能想到的只是某种通信开销或MySQL错误，可能导致它重新计算每一行的结果集。您是如何衡量性能差异的？我使用一个简单的计时器（

time

module in python）您能检查一下，40次迭代中的每一次是否需要相同的时间吗，或者是否有一些启动开销。如果您指的是密钥缓存的角色，它确实起到了一定的作用，那么在不同查询中使用不同的游标之间仍然存在明显的差异。关于不同类型的游标之间的差异，是否有权威资源？