tidb索引优化问题

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

【概述】 场景 + 问题概述
表里有两个字段country_id 和 account_id, 在这两个字段上各自建了索引,用where country_id=1 and account_id=1111查询时有时候命中的country_id的索引,有时候走account_id的,请问下,tidb的索引
命中逻辑是怎样的?谢谢!
【应用框架及开发适配业务逻辑】

【背景】 做过哪些操作

【现象】 业务和数据库现象

【问题】 当前遇到的问题

【业务影响】

【TiDB 版本】 v5.0.0

【附件】 相关日志及监控(https://metricstool.pingcap.com/)


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

1赞

tidb_enable_index_merge默认是off,两个字段分别是两个索引,每次只会扫描一个索引。如果设置为true,会扫描两个索引确定PK后,再来回表查询。

1赞

谢谢!

1赞

目前,TiDB 的 IndexMerge 特性在 TiDB 4.0.0-rc.1 版本中默认关闭。同时 4.0 版本中的 IndexMerge 目前支持的场景仅限于析取范式( or 连接的表达式),暂不支持合取范式( and 连接的表达式)。

请问5.0是怎样子的?谢谢!

1赞

请问使用indexmerge的坏处是啥?找了下资料没找到

1赞

默认就是 off

1赞

没有什么坏处,5.0也是默认off,可能会扰乱执行计划。

1赞

谢谢!
暂不支持合取范式( and 连接的表达式)
请问这个在5.0还是这样吗? 我sql就是and查询的

1赞

还是一样,那就建立一个联合索引

1赞

是的,加了联合索引解决了,想了解下原因,谢谢了。。

1赞

and查询还是建议用联合索引,效率也比indexmerge高,如果统计信息不准确,可能会导致and查询使用indexmerge的效率还不如使用单列索引,在mysql中经常会遇到这个问题

1赞

谢谢! 我深入了解下

1赞

索引不是越多越好,以命中率为准~

索引也和普通 value 一样,需要做 insert ,会额外占用资源

1赞

是的,数据会多很多

1赞

关于哪个索引选择的问题: 这里就是 and 连接的两种 accessPath, 在的这个 #26304 commit 之后, 应该会固定使用一个索引

// Find the unique index with the minimal number of ranges as `uniqueBest`.
			if uniqueBest == nil || len(uniqueIdx.Ranges) < len(uniqueBest.Ranges) {
				uniqueBest = uniqueIdx
			}

索引选择会根据统计信息预估耗费,选择耗费更低的,对于你的查询,建议采用联合索引,效率最佳

谢谢!