在中,它使用覆盖索引来优化像这样的限制查询。我使用了从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吗?
1条答案
按热度按时间5cg8jx4n1#
EXPLAIN
因为忽视而臭名昭著LIMIT
价值观。这里有一个更好的方法来感受正在发生的事情:
使用一个类似的查询(5.6)对一些数据,我有。。。
(该表有5484行。)
解释:
所以。。。没有表格扫描。这个
OFFSET
仅包含在派生表中。这个
Using index
在你的EXPLAIN
(和我的)确认使用了“覆盖指数”。(我想……)在旧版本中,
EXPLAIN
将实际计算任何派生表;8.0避免了这种情况。这可以部分解释为什么你的两个输出发生了变化。