Mybatis查询导致TiDB索引失效

为提高效率,请提供以下信息,问题描述清晰能够更快得到解决:
【 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为关联字段

Navicat查询耗时

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


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

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

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

我刚刚写错了 company表是b表

可以发一下 执行计划

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

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

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

看下sql的执行计划

还是要具体看下你这个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的执行计划

b.eid = a.eid

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

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

该主题在最后一个回复创建后60天后自动关闭。不再允许新的回复。