covering索引不能优化limit查询

在中，它使用覆盖索引来优化像这样的限制查询。我使用了从mysql官网下载的sakila数据库。以下是查询：

SELECT a.film_id, a.description 
  from sakila.film a 
  inner join (
    select film_id 
      from sakila.film b 
      order by title limit 50,5
  ) as lim 
  USING(film_id)

但我用解释来分析这个过程。看起来像这样。

在第三行中，它显示它仍然扫描所有1000行。然后我测试了子查询 select film_id from sakila.film b order by title limit 50,5 ，解释日志如下

.
在我看来，第一个日志中的第三行应该和第二个日志一样，我不知道如何解释第一个日志中的前两行，为什么行是55和1，我想它们应该是5和5。这是mysql的官方演示。我想这是因为mysql的版本。
我把我的mysql更新到8.0.11.0版本，这样会更正常一些

我在mysql8.0和mysql5.6中测试了相同的数据集，在mysql5.6中它只需要0.2秒来检索数据，但是在mysql8.0中它需要1秒来完成。它们有什么不同？第一排仍然是905而不是5。有人能告诉我为什么第一排是905，第二排是1吗？

EXPLAIN 因为忽视而臭名昭著 LIMIT 价值观。
这里有一个更好的方法来感受正在发生的事情：

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

使用一个类似的查询（5.6）对一些数据，我有。。。

SELECT  city, province, population
    FROM  canada AS a
    JOIN ( SELECT  id
            FROM  canada
            ORDER BY  city
            LIMIT  300,20    -- I used bigger numbers
         ) AS x USING(id);

（该表有5484行。）

mysql> SHOW SESSION STATUS LIKE 'Handler%';
+----------------------------+-------+
| Variable_name              | Value |
+----------------------------+-------+
| Handler_commit             | 1     |
| Handler_delete             | 0     |
| Handler_discover           | 0     |
| Handler_external_lock      | 4     |
| Handler_mrr_init           | 0     |
| Handler_prepare            | 0     |
| Handler_read_first         | 1     |
| Handler_read_key           | 21    |  -- about 20
| Handler_read_last          | 0     |
| Handler_read_next          | 319   |  -- about 300+20 (OFFSET+LIMIT)
| Handler_read_prev          | 0     |
| Handler_read_rnd           | 0     |
| Handler_read_rnd_next      | 21    |  -- about 20
| Handler_rollback           | 0     |
| Handler_savepoint          | 0     |
| Handler_savepoint_rollback | 0     |
| Handler_update             | 0     |
| Handler_write              | 20    |  -- 20  (the 'derived' table)
+----------------------------+-------+
18 rows in set (0.00 sec)

解释：

+----+-------------+------------+--------+---------------+---------+---------+------+------+-------------+
| id | select_type | table      | type   | possible_keys | key     | key_len | ref  | rows | Extra       |
+----+-------------+------------+--------+---------------+---------+---------+------+------+-------------+
|  1 | PRIMARY     | <derived2> | ALL    | NULL          | NULL    | NULL    | NULL |  320 | NULL        |
|  1 | PRIMARY     | a          | eq_ref | id            | id      | 4       | x.id |    1 | NULL        |
|  2 | DERIVED     | canada     | index  | NULL          | city_id | 771     | NULL | 5484 | Using index |
+----+-------------+------------+--------+---------------+---------+---------+------+------+-------------+

所以。。。没有表格扫描。这个 OFFSET 仅包含在派生表中。
这个 Using index 在你的 EXPLAIN （和我的）确认使用了“覆盖指数”。
（我想……）在旧版本中， EXPLAIN 将实际计算任何派生表；8.0避免了这种情况。这可以部分解释为什么你的两个输出发生了变化。

covering索引不能优化limit查询

1条答案

相关问题

热门标签

最新问答