查询优化的问题,range范围大查询更快

为提高效率,提问时请提供以下信息,问题描述清晰可优先响应。

  • 【TiDB 版本】:v3.1.0-beta
  • 【问题描述】:同样的SQL,range范围大查询更快,使用索引比没用索引慢 若提问为性能优化、故障排查类问题,请下载脚本运行。终端输出打印结果,请务必全选并复制粘贴上传。

这两条 SQL 的查询范围不一样,第一条 SQL 加上 use index() 让他走全范围的 table scan 看看 explain analyze 的执行结果呢?

加上之后,会使用索引;但是使用索引感觉会变慢,每个business_date有20万左右数据。

麻烦在 business_data range 相同的情况下 通过 use index() 提供下走索引以及全表( primary key )的 explain analyze 的结果。

这是range相同的

这是全表的

能否再提供下基于 between ‘2019-08-20’ and ‘2019-09-20’ 的 explain analyze 的两种结果?

这个是都走索引了

麻烦把 use index 部分改成 use index (PRIMARY) 看下效果。

use index(primary)变得更慢了

  1. 麻烦给下 show create table的结果
  2. use index (PRIMARY) 的 hint 改成用 ignore index (business_date , {other_index_name} ) 再看下结果

1.表结构,表有点大,粘出来了

2.不用索引会变快

麻烦在业务低峰的时候执行一下 analyze table {table_name} ,之后再执行一下看下不加 hint 的 explain analyze 的结果。

我们分析了下执行计划,business_date粒度太粗,每个有差不多20万条数据,走索引的话,root task执行的时候会拉取很多数据,有差不多5.5万条数据,而不走索引的root task只会拉取2000多条数据,这个应该是变慢的真正原因。索引粒度过粗对于查询并不一定有帮助

建议 analyze table 之后再看下结果

analyze也没有什么问题 image

再提供下 explain analyze 的结果看下。不加 hint 的。

看起来好像没有什么变化

看起来两个查询的时间相差不远,应该是优化器对于当前 cost 的评估人为 index scan 比较小,所以走的 index scan 了。而且 index scan 与 tablescan 的估算应该是差不多,所以后续如果 where 条件的 date range 再调大的话会自动选择 tablescan。

对,这种情况可以通过建分区表来规避。

:+1: