SQL 提高效率：LIMIT the amount of FILESORT

Question

我将通过这样的查询来解释自己：(post_id=PRIMARY, blog_id=index)

SELECT post_id FROM posts WHERE blog_id IN (2,3,...) ORDER BY post_id DESC LIMIT 10

更新：IN() 中的 id 可能很多。 如果数据库使用 blog_id 作为查询的键，它必须进行文件排序，因为索引看起来像这样：

(blog_id,post_id)-> (1,55) (1,59) (1,69) (2,57) (2,71) (2,72) (3,12)

如果您只搜索一个 id blog_id = 2 而不是 IN()，则不需要进行任何文件排序，因为所有匹配项都已按顺序排列。

我认为它正在发生的问题，不是 100% 肯定，而是通过查看查询执行时间，如果我添加一个 LIMIT 10 有效的方法是只捕获和文件排序每个 blog_id 的最后 10 个 id索引键匹配，也许它已经这样做了，但看起来对于 IN (2,3,4) ORDER BY post_id DESC LIMIT 10，它对数千个 id 进行排序而不是 30。

我希望我完全错了，因为如果我不是，那将是一个可怕的低效错误。 如果我是对的，我可以做任何引擎或改变吗？甚至更改数据库。目前我在 10.1.13-MariaDB 并且表是 InnoDB

Answer 1

不幸的是，MySQL 没有索引可以让您随心所欲。

但是，您可以重写您的查询并使用现有索引：

SELECT p.post_id
FROM ((SELECT post_id
       FROM posts
       WHERE blog_id = 2
       ORDER BY post_id DESC
       LIMIT 10
      ) UNION ALL
      (SELECT post_id
       FROM posts
       WHERE blog_id = 3
       ORDER BY post_id DESC
       LIMIT 10
      )
     ) p
ORDER BY post_id DESC
LIMIT 10;

每个子查询都会使用索引。对 20 个元素进行排序非常快。

Answer 2

看EXPLAIN SELECT ...;看看它是否说“文件排序”。

执行以下操作以获取详细信息，即使是小型数据集：

FLUSH STATUS;
SELECT ...;
SHOW SESSION STATUS LIKE 'Handler%';

您确实需要INDEX(blog_id, post_id)。如果您使用的是 InnoDB 并且该表有

PRIMARY KEY(post_id),
INDEX(blog_id)

那么你确实有那个复合索引。这是因为每个二级索引都隐含包含 PK 的列。

由于您使用的是 MariaDB，请查看 LIMIT ROWS EXAMINED 是否会执行您询问的其他事情。

当优化器看到这个时：

WHERE blog_id IN (2,3)
ORDER BY post_id DESC LIMIT 10

它同时拥有INDEX(blog_id) 和INDEX(post_id)，它会根据有限的统计数据做出决定：走哪条路：

计划 A：过滤 blog_id + 文件排序，或
方案 B：按 post_id 顺序扫描，希望尽快找到 10 行。

任何一个都有风险。计划 A，如果大多数或所有行都是 (2,3)，将有一个大排序。方案 B，当匹配的行数少于 10 时，将扫描整个表（或索引）。