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

相关推荐
缘来如此҉16 分钟前
Mysql数据库——增删改查CRUD
数据库·mysql·oracle
apihz38 分钟前
域名WHOIS信息查询免费API使用指南
android·开发语言·数据库·网络协议·tcp/ip
gwcgwcjava44 分钟前
[时序数据库-iotdb]时序数据库iotdb的安装部署
数据库·时序数据库·iotdb
SHUIPING_YANG1 小时前
根据用户id自动切换表查询
java·服务器·数据库
爱吃烤鸡翅的酸菜鱼1 小时前
IDEA高效开发:Database Navigator插件安装与核心使用指南
java·开发语言·数据库·编辑器·intellij-idea·database
超奇电子1 小时前
阿里云OSS预签名URL上传与临时凭证上传的技术对比分析
数据库·阿里云·云计算
modelmd1 小时前
mysql not in 查询引发的bug问题记录
sql·mysql
神仙别闹1 小时前
基于C#+SQL Server实现(Web)学生选课管理系统
前端·数据库·c#
m0_653031362 小时前
PostgreSQL技术大讲堂 - 第97讲:PG数据库编码和区域(locale)答疑解惑
数据库·postgresql
会编程的林俊杰2 小时前
MySQL中的锁有哪些
数据库·mysql