Mybatis查询导致TiDB索引失效

#1

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

【概述】
【SQL】
SELECT
a.*
FROM
records a
LEFT JOIN company b ON b.eid = a.eid
WHERE
b.id = ?
ORDER BY
a.change_date DESC
由b表企业ID查询企业下业务记录，b表id为主键，eid为索引key，a表无主键，由eid和u_id 组成唯一键，eid为关联字段

image
image.png1878×400 696 KB

Navicat查询耗时

image
image.png1499×511 132 KB

【问题】数据从mysql迁移至TiDB，废弃了原表的自增主键，采用多字段联合唯一key，原有的业务查询sql在Navicat中查询没有问题，耗时0.3s，但是在程序中Mybatis查询很慢，数十秒，甚至几分钟，数据库连接池使用的是Hikiri。

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

#2

这里的 LEFT JOIN company a 应该是 LEFT JOIN company b 吗？
我看到您的截图中有打印 MyBatis 运行的 SQL，可否复制一下？

#3

还有表结构也麻烦给一下，我尝试在本地复现一下。

#4

我刚刚写错了 company表是b表

#5

可以发一下 执行计划

#6

dashboard 上的 sql 分析 可以查看详细细节啊

#7

表结构发下 , 我也试试 , 不行再建个组合索引呗

#8

确认一下是哪里的问题，可以在dashboard慢sql 查询sql的执行时间，如果很慢就看看tidb的资源使用情况

#9

看下sql的执行计划

#10

还是要具体看下你这个SQL的执行计划。首先你这个SQL是个假的外连接，优化器会直接改写成如下内连接：

SELECT a.*
  FROM records a, company b 
 WHERE a.eid = b.eid
   AND b.id = ?
 ORDER BY a.change_date DESC

然后，按照你描述的，估计就是a表和b表的JOIN方式变了：
1、如果是a表驱动b表，那a表就是全表扫描，b表走eid索引(IndexJoin)或者id主键(HashJoin)
2、如果是b表驱动a表，那b表走id主键，a表走(eid, u_id)索引(IndexJoin)或者全表扫描
所以大概至少就有上述4种JOIN方式，具体谁更优还要看你a表的行数规模以及a.eid字段的筛选能力，所以需要对比Mybatis和Navicat下SQL的执行计划

#11

b.eid = a.eid

b.id =
检查一下这几个列，这几个都有索引吗？

#12

可以看一下执行计划，是不是有全表扫描