覆盖索引

为提高效率,请提供以下信息,问题描述清晰能够更快得到解决:
【 TiDB 使用环境】

kubernetes
【概述】 场景 + 问题概述
对于通过索引查找如果查询条件包含所有的列,比如只查询了主键,可以使用覆盖索引的特性,不需要回表,提升查询的性能
【背景】 做过哪些操作
内部数据库表做了垂直拆分,对于查询列和存放数据的列分成两张表,通过相同的主键来关联两个表的数据,主键是同过snowflake生成地uint64的整数类型,通过查询条件表,返回符合条件的主键,再通过主键在数据表查询结果
【现象】 业务和数据库现象
查询条件表的时候发现没有使用覆盖索引
【问题】 当前遇到的问题

【业务影响】
查询条件表多了一次回表,影响数据库查询的性能
【TiDB 版本】
4.0.8
【应用软件及版本】

【附件】 相关日志及配置信息

  • TiUP Cluster Display 信息
  • TiUP CLuster Edit config 信息

监控(https://metricstool.pingcap.com/)

  • TiDB-Overview Grafana监控
  • TiDB Grafana 监控
  • TiKV Grafana 监控
  • PD Grafana 监控
  • 对应模块日志(包含问题前后 1 小时日志)

若提问为性能优化、故障排查类问题,请下载脚本运行。终端输出的打印结果,请务必全选并复制粘贴上传。

1赞

这个需要提供具体的 SQL语句 及其 执行计划(explain analyze )

1赞

feature_id是主键,并且按照tidb中int_only的特性,feature_id还是row_id,在IndexRangeScan_8这一步已经可以获取到,但是发现又多了一次不必要的回表

1赞

同样的语句在mysql中执行发现是命中了覆盖索引

1赞

:joy: 能提供一下建表语句吗(可以脱敏),我没有复现出来:rofl:(刚才测试了一下 主键非 int 型的,和你情况是一样的,建议你检查一下主键到底是不是 int 类型?)

1赞

create.txt (16.8 KB)

1赞

uint64类型,我是通过这个执行计划证明了确实是用了我的主键作为row_id

1赞

:sweat_smile:用你的表结构,和集群版本,都没有模拟出来

1赞

我的tidb是4.0.8版本,我看5.0的release note中也没有关于覆盖索引的优化

1赞

我的主键作为row_id这个环节我们是一致的吧


你的这几个执行计划表接口可以发出来,还有表结构,我对比一下

1赞

1赞

你的tidb是哪个版本,看起来确实使用了覆盖索引

有没有安装tiflash

这个和 tiflash 没关系,我使用的 tiup playground 模式创建了 4.0.8 的

好吧,tidb和tikv关于索引主键这块有什么配置吗,是不是我们设置的主键配置不一样
https://docs.pingcap.com/zh/tidb/stable/clustered-indexes

这里4.0版本找到了覆盖索引
https://docs.pingcap.com/zh/tidb/v4.0/explain-indexes#indexreader
但是我的tidb集群却不支持,这个是不是我有些tidb的配置出错了

覆盖索引和 cluster index 不是一个东西,这个和配置也没关系

这个问一下,你这个 执行计划 是稳定复现的,还是偶尔的

稳定复现