Sqlite ORDER BY 组的计数很慢答案

【问题标题】：Sqlite ORDER BY group's count is slowSqlite ORDER BY 组的计数很慢
【发布时间】：2012-10-14 00:09:14
【问题描述】：

当我在查询中添加 ORDER BY 语句时，它变得非常慢。

这是我没有 ORDER BY 的查询：

SELECT ClientIpAddress, Agentstring, Count(ClientIpAddress) AS Count FROM LogEntries
WHERE SiteIisId = 3 AND DateTime >= '13-09-2012 00:00:00'
GROUP BY ClientIpAddress, Agentstring
LIMIT 5

ET：1 毫秒

现在使用 ORDER BY:

SELECT ClientIpAddress, Agentstring, Count(ClientIpAddress) AS Count FROM LogEntries
WHERE SiteIisId = 3 AND DateTime >= '13-09-2012 00:00:00'
GROUP BY ClientIpAddress, Agentstring
ORDER BY Count DESC
LIMIT 5

ET：294 毫秒

我正在查询的表包含 1.380.855 行。

这是我正在使用的索引：

CREATE INDEX "LogEntries_MostActiveClients" ON "LogEntries" ("ClientIpAddress" ASC, "Agentstring" ASC, "SiteIisId" ASC, "DateTime" DESC)

使用EXPLAIN QUERY PLAN Sqlite 告诉我它正在使用我的索引扫描表，并且正在使用TEMB B-TREE作为我的Order By。

我该如何克服这个问题？显然我无法索引Count，那该怎么办？

谢谢一百万！

【问题讨论】：

请注意，DateTime 上的比较不能正常工作，因为它没有从最重要的字段开始，即年份。您应该使用supported date formats 之一。
对不起，我已经添加了正在使用的索引。感谢您指出 DateTime 问题。

标签： sqlite group-by sql-order-by

【解决方案1】：

当您单步执行结果集时，SQLite 会尝试动态计算尽可能多的值。

因此，在您的第一个查询中，SQLite 永远不需要对表中的所有地址/代理值进行分组；只要它通过某个索引读取了前五个ClientIpAddress/Agentstring组合的记录，就可以停止。

在您的第二个查询中，这是不可能的：必须完全计算所有地址/代理组，然后才能对其进行排序并选择前五个。

待排序的临时结果中的记录已经在缓存中，并且比原表中的数据小，所以我猜大部分时间不是排序，而是分组。

如果排序有问题，并且您估计了五个最大计数的大小，您可以尝试添加 HAVING "Count" >= some_limit 子句以减少要排序的记录数。

您无法避免分组。您可以尝试的只是通过通用优化获得小的改进，例如：

将 SQLite 的 page cache 增加到你的工作集的大小；和
创建一个covering index 以避免在表本身中进行查找（您已经有了）。

另一种方法是预先计算此查询的值：使用您的 Count 有一个单独的表，并在您添加日志条目时更新它。这将使这些更新变慢，您必须确定时间戳的粒度。

【讨论】：

感谢您的回答。不幸的是，添加HAVING 语句只会增加执行时间（有或没有ORDER BY）。你有什么建议我可以克服这个问题吗？不一定非要采用这种方法。

【解决方案2】：

使用找到的 SQLite 合并测试您的应用程序 here。

Richard Hipp 最近宣布：

我们最近对查询进行了多项重大改进 SQLite 中的优化器。特别是，最新的代码做得更好识别何时可以通过仔细选择满足 ORDER BY 子句索引和扫描顺序，无需进行任何排序。这优化可以显着提高查询的性能具有大型结果集。

电子邮件线程是here。

【讨论】：

这些增强仅适用于由于某些索引或GROUP BY而导致结果已经排序的情况。
是的，如果没有合适的索引，您需要添加它。