分页查询的高成本答案

【问题标题】：High cost for a pagination query分页查询的高成本
【发布时间】：2021-11-14 09:22:54
【问题描述】：

我有一个分页查询，它对一个大表进行范围索引扫描：

create table t_dummy (
  id int not null auto_increment,
  field1 varchar(255) not null,
  updated_ts timestamp null default null,
  primary key (id),
  key idx_name (updated_ts)

查询如下所示：

select * from t_dummy a
where a.field1 = 'VALUE'
and (a.updated_ts > 'some time' or (a.updated_ts = 'some time' and a.id > x)
order by a.updated_ts, a.id
limit 100

解释计划显示成本很高，rows 值非常高，但是，它使用了所有正确的索引并且执行似乎很快。有人能告诉我这是否意味着查询效率低吗？

【问题讨论】：

首先我想提一下，你创建的表和你引用的表是不一样的。关于查询成本的问题为什么不使用a.updated_ts>='some time' and a.id>x 可以帮助您优化查询的另一件事是尝试从查询中删除 order by 子句。 order by 子句会在查询的输出上产生开销，因为它首先根据updated_ts 对输出进行排序，然后再次对id 执行排序操作。希望你明白我想告诉你的意思。
感谢您指出不匹配。更正。我也喜欢 and 子句优化。但是我需要按该顺序对结果进行排序。
再想一想，AND 重构是不正确的@ShaktiK ;) 感谢您的回复
我认为他们的意思是和重构就像我的回答一样

标签： mysql pagination sql-execution-plan

【解决方案1】：

EXPLAIN 可能会产生误导。它可以报告rows 的高值，尽管一旦发现足够多的行满足您请求的 LIMIT（在您的情况下为 100），MySQL optimizes LIMIT queries 就会停止。

问题是，在查询执行 EXPLAIN 时，它不一定知道需要检查多少行才能找到至少 100 行满足 WHERE 子句中的条件。

因此，当您有 LIMIT 查询时，通常可以忽略 EXPLAIN 的 rows 字段。它可能真的不需要检查这么多行。

【讨论】：

感谢您的回答，比尔。这很有帮助

【解决方案2】：

如果执行速度足够快，请不要担心。如果不是，请考虑使用(field1,updated_ts) 索引和/或将您的查询更改为

and a.updated_ts >= 'some time' and (a.updated_ts > 'some time' or a.id > x)

【讨论】：

【解决方案3】：

正如比尔所说，不能相信 Explain 会考虑 LIMIT。

以下将确认查询仅涉及 100 行：

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

Handler_read% 的值加起来可能约为 100。可能没有 Handler_write% 值——它们表示临时表的创建。

提示：如果您使用LIMIT 101，则会显示 100 行，以及是否还有更多行的指示。这以非常低的成本避免了有时会出现空白页的 [下一步] 按钮。

我关于这个话题的提示：http://mysql.rjweb.org/doc.php/pagination

【讨论】：

这很有趣，谢谢，除了 EXPLAIN ANALYZE 之外，我还在寻找其他东西来查看实际成本。它显示“Handler_read_next = 99”，看不到writes。 rows 大约占总行数的 40%，但速度很快
@user3621726 - 除了 1 个“第一”行之外，还有 99 个“下一个”行。尽管EXPLAIN 说了什么，但查询是有效的。慢日志还会说“访问的行数：100”