为提高效率,请提供以下信息,问题描述清晰能够更快得到解决:
【 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 个赞
spc_monkey
(carry@pingcap.com)
2
这个需要提供具体的 SQL语句 及其 执行计划(explain analyze )
1 个赞
feature_id是主键,并且按照tidb中int_only的特性,feature_id还是row_id,在IndexRangeScan_8这一步已经可以获取到,但是发现又多了一次不必要的回表
1 个赞
spc_monkey
(carry@pingcap.com)
5
能提供一下建表语句吗(可以脱敏),我没有复现出来(刚才测试了一下 主键非 int 型的,和你情况是一样的,建议你检查一下主键到底是不是 int 类型?)
1 个赞
uint64类型,我是通过这个执行计划证明了确实是用了我的主键作为row_id
1 个赞
我的tidb是4.0.8版本,我看5.0的release note中也没有关于覆盖索引的优化
1 个赞
我的主键作为row_id这个环节我们是一致的吧
你的这几个执行计划表接口可以发出来,还有表结构,我对比一下
1 个赞
spc_monkey
(carry@pingcap.com)
15
这个和 tiflash 没关系,我使用的 tiup playground 模式创建了 4.0.8 的
spc_monkey
(carry@pingcap.com)
18
覆盖索引和 cluster index 不是一个东西,这个和配置也没关系
spc_monkey
(carry@pingcap.com)
19
这个问一下,你这个 执行计划 是稳定复现的,还是偶尔的