整数列上的聚集索引出奇地慢

Question

我有一个包含 750,000 条记录的 InnoDB 表。它的主键是BIGINT。

当我这样做时：

SELECT COUNT(*) FROM table;

需要 900 毫秒。 explain 表示没有使用索引。

当我这样做时：

SELECT COUNT(*) FROM table WHERE pk >= 3000000;

需要 400 毫秒。 explain 表明在这种情况下使用了索引。

我希望在x >= pk >= y 的位置进行快速计数。

据我了解，由于我使用表的主键，因此我使用的是聚集索引，因此行（物理上？）由该索引排序。那么做这个计数不应该非常非常快吗？我原以为结果会在十几毫秒左右提供。

我已经读过，如果我只选择表格的一小部分，可以预期更快的结果。然而，我对做这些范围计数很感兴趣。也许我应该以不同的方式组织我的数据？

在另一种情况下，我有一个包含空间数据的表并使用 RTREE 索引，然后我使用 MBRContains 来计算匹配行（以及二级索引）。令人惊讶的是，这比上面的简单情况要快。

Answer 1

在 InnoDB 中，PRIMARY KEY 与数据“聚集”在一起。这意味着数据按 PK 排序，where pk BETWEEN x AND y 必须读取从x 到y 的所有行。

那么，它是如何进行 PK 扫描的呢？它必须读取数据块。它们体积庞大，因为它们还有其他列。

但是没有WHERE 的COUNT(*) 呢？在这种情况下，优化器会查找体积最小的索引并计算其中的行数。所以...

如果您有二级索引，它将使用它。

如果你只有PK，那么它会读取整个表来做计数。

也就是说，在最窄的列上人为添加二级索引很可能会加速SELECT COUNT(*) FROM tbl。

但是等等...确保每次计时测试运行两次。第一次（重新启动后）必须从磁盘读取所需的块。慢。

第二次所有块都可能位于 RAM 中。更快。

SPATIAL 和 FULLTEXT 索引使这个讨论变得复杂。特别是如果您有 2 个部分到 WHERE，一个带有空间或全文，一个带有常规测试。

COUNT(1) 和 COUNT(*) 是相同的。 COUNT(x) 在将行包含在计数中之前检查 x 是否为 NOT NULL。