为提高效率,请提供以下信息,问题描述清晰能够更快得到解决:
【 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。
若提问为性能优化、故障排查 类问题,请下载脚本 运行。终端输出的打印结果,请务必全选 并复制粘贴上传。
Icemap
(Icemap)
2022 年6 月 28 日 10:18
2
这里的 LEFT JOIN company a
应该是 LEFT JOIN company b
吗?
我看到您的截图中有打印 MyBatis 运行的 SQL,可否复制一下?
边城元元
(边城元元)
2022 年6 月 28 日 10:51
6
dashboard 上的 sql 分析 可以查看详细细节啊
表结构发下 , 我也试试 , 不行再建个组合索引呗
确认一下是哪里的问题,可以在dashboard慢sql 查询sql的执行时间,如果很慢就看看tidb的资源使用情况
还是要具体看下你这个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 =
检查一下这几个列,这几个都有索引吗?
system
(system)
关闭
2022 年9 月 20 日 02:13
13
该主题在最后一个回复创建后60天后自动关闭。不再允许新的回复。