Question

＆lt;高性能Mysql＆gt; ，它使用覆盖索引来优化这样的限制查询。我使用从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，它更像这样

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

Answer 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确认使用＆＃34;覆盖索引＆＃34;。

（我认为......）在旧版本中，EXPLAIN实际上会评估任何Derived表; 8.0避免这种情况。这可以部分解释为什么 Explain 在您的两个输出中发生了变化。

覆盖索引无法优化mysql8.0中的限制查询

1 个答案: