tidb无法命中索引的问题&sql性能调优

【TiDB 使用环境】生产环境
【TiDB 版本】7.5.1
【操作系统】centos
【部署方式】物理机部署

【集群节点数】3

【遇到的问题:问题现象及影响】
背景:
tb_card 数据量 60w+,tb_customer 数据量 60w+

tb_customer表的c_no 和 tb_card表中c_customer 进行关联。

tb_customer 表索引情况如下:

tb_card 表索引如下:

生产环境中程序中运行了如下的一个sql,执行起来比较慢:

SELECT
a.c_no AS CustNo,
a.c_name AS CustName,
a.c_id AS IdCardNo,
a.c_tele AS Phone,
cd.c_cardno AS CardNo,
cd.c_status AS CardStatus
FROM
tb_card cd
INNER JOIN tb_customer a ON cd.c_org_id = a.c_org_id
AND cd.c_customer = a.c_no
WHERE
a.c_org_id = ‘8’
AND a.c_id = ‘513022199412206825’

实际执行的计划和预估的执行计划不一致:

预估计划如下:

实际执行计划如下:

两个表的健康度如下:

性能差很多,请教下各位可能是哪里的问题?

另外,如果脚本中强制使用tb_card 的 IX_tb_card_customer 索引时,效率就会提升很多。

是哪里影响tidb选择索引了?

同样的脚本,在另外一个项目上执行,索引是正常命中


健康度准么?差这么多…

我也是怀疑这个,98的健康度,应该是正常的;晚上手工执行下 analyze table tb_card 再试试

tb_customer健康比较低。
也analyze。。

也可以绑定下执行计划

两个表现分析一下。也就是收集一下统计信息

这里能命中,应该是没有数据原因。

tb_card建一个组合索引,c_customer,c_org_id 看下会不会走

:slightly_smiling_face:
tb_card 是有组合索引的,并且我在sql中强制指定这个索引,执行效率是没问题

c_org_id的基数这么低不适合当复合索引的第一位

1 个赞

表是聚簇表吧,走到联合主键去了。c_org_id的选择性不行,你可以把主键的顺序换下。建索引的规则楼上也说了,选择性高的放前面,不止是优化器估算会准,执行也会更快。

跟进关注学习 :pray:

先收集一下数据库统计信息试试,如果不行就用hint影响一下看看能不能强制走索引

统计信息更新了嘛?