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查询。

相关推荐
互联网搬砖老肖1 小时前
运维打铁: MongoDB 数据库集群搭建与管理
运维·数据库·mongodb
典学长编程2 小时前
数据库Oracle从入门到精通!第四天(并发、锁、视图)
数据库·oracle
积跬步,慕至千里3 小时前
clickhouse数据库表和doris数据库表迁移starrocks数据库时建表注意事项总结
数据库·clickhouse
极限实验室3 小时前
搭建持久化的 INFINI Console 与 Easysearch 容器环境
数据库
修电脑的猫3 小时前
Performance Monitoring on Production Systems in SAP ERP(ABAP性能优化)
性能优化·abap
星辰离彬3 小时前
Java 与 MySQL 性能优化:Java应用中MySQL慢SQL诊断与优化实战
java·后端·sql·mysql·性能优化
白仑色4 小时前
Oracle PL/SQL 编程基础详解(从块结构到游标操作)
数据库·oracle·数据库开发·存储过程·plsql编程
程序猿小D5 小时前
[附源码+数据库+毕业论文]基于Spring+MyBatis+MySQL+Maven+jsp实现的个人财务管理系统,推荐!
java·数据库·mysql·spring·毕业论文·ssm框架·个人财务管理系统
钢铁男儿6 小时前
C# 接口(什么是接口)
java·数据库·c#
__风__7 小时前
PostgreSQL kv(jsonb)存储
数据库·postgresql