MySQL | 查询接口性能调优、编码方式不一致导致索引失效

背景

最近业务反馈,列表查询速度过慢,需要优化。

到正式环境系统去验证,发现没筛选任何条件的情况下,查询需要三十多秒,而筛选了条件之后需要13秒。急需优化。

先说结论:连表用的字段编码方式不一致导致索引不可用。

SQL验证

1.本地运行项目,找到相应的查询接口,利用MbBatis Log插件获取到分页查询的SQL,拿到数据库去运行,18秒,好久。

2.而且,因为项目使用的是jeecgboot项目,分页在分页查询之后会先查询总数,拿查总数的SQL来验证。也是要13秒,太慢啦。

看看执行计划

3.从SQL来看,u表有用到主键id来做关联,照理说索引应该用主键才对,但执行计划显示并没有使用主键。尝试把u表相关的关联表去掉看看是不是这个表的原因。

4.速度大幅度提高,说明问题确实出现在u表相关的几个表。去看看u表的结构。索引是存在的,但却并没有用到,很奇怪。再看看编码方式。

5.再对比一下关联的hr表的sys_user_id字段

6.两个字段的编码方式不一样,尝试把u表的编码方式改成和hr表一致。再运行SQL。

7.速度提升不明显,再看看执行计划。

8.ud表好像也有点问题,索引类型不太正常,看了一下表结构,发现也是编码问题,顺便也改了(d表也有一样问题,也改了)。

9.看看分页查询的速度

10.这个速度还可以,再看看执行计划。索引的类型现在要么是eq_ref,要么是ref,并且能用主键的基本也是用主键,符合预期了。

修改前后执行计划对比



11.最后去系统体验,查询速度大概是3.6秒,相比一开始的30多秒,速度提升了七八倍。

分析

本来u表的数据量并不大,但其他表连接之后,数据量已经非常大了,u表的速度稍微慢一点都会很明显。而u表几乎是全表扫描,也就出现了整个接口速度很慢的场景。

想要继续调优,目前的打算是把一部分主查询没有用来筛选的字段拆分开,在外层先查出来再在主SQL里面用in查询。

相关推荐
xhbh6662 小时前
不止是DELETE:MySQL多表关联删除的JOIN语法实战详解
数据库·mysql·程序员·mysql删除语句
不掰手腕2 小时前
在UnionTech OS Server 20 (统信UOS服务器版) 上离线安装PostgreSQL (pgsql) 数据库
linux·数据库·postgresql
MAGICIAN...2 小时前
【Redis五种数据类型】
数据库·redis·缓存
yddddddy3 小时前
SQLite的基本操作
数据库·sqlite
华科云商xiao徐3 小时前
Java并发编程常见“坑”与填坑指南
javascript·数据库·爬虫
知其然亦知其所以然3 小时前
面试官微笑发问:第100万页怎么查?我差点当场沉默…
后端·mysql·面试
广州腾科助你拿下华为认证3 小时前
PostgreSQL认证_PGCM考试难度有多大?
数据库·postgresql
代码的余温3 小时前
Oracle RAC认证矩阵:规避风险的关键指南
数据库·oracle·矩阵
白鲸开源3 小时前
一行代码引发 12G 内存 5 分钟爆仓!SeaTunnel Kafka 连接器"内存溢出"元凶抓到了
数据库·kafka·开源