tidb索引优化问题

[Christophe (Doudouwyh)]

为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：
【 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/)

---

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

[Meditator (Wendywong020)]

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

[Christophe (Doudouwyh)]

谢谢！

[Christophe (Doudouwyh)]

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

请问5.0是怎样子的？谢谢！

[Christophe (Doudouwyh)]

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

[xfworld (魔幻之翼)]

默认就是 off

[Meditator (Wendywong020)]

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

[Christophe (Doudouwyh)]

谢谢！
暂不支持合取范式（ and 连接的表达式）
请问这个在5.0还是这样吗？ 我sql就是and查询的

[Meditator (Wendywong020)]

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

[Christophe (Doudouwyh)]

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

[啦啦啦啦啦]

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

[Christophe (Doudouwyh)]

谢谢! 我深入了解下

[xfworld (魔幻之翼)]

索引不是越多越好，以命中率为准～

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

[Christophe (Doudouwyh)]

是的，数据会多很多

[AilinKid-PingCAP (Arenatlx)]

关于哪个索引选择的问题: 这里就是 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
			}

[lixiansheng (李仕豪)]

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

[Christophe (Doudouwyh)]

谢谢！