小小的改动,竟然效率提高了1000倍

前言

小小的改动,竟然让SQL 效率提高了1000倍🚀

今天又是被国产环境教育的一天😭!!!!!

同样的SQL同样的数据,迁移了服务器,升级了一个小的数据库版本之后,直接导致查询效率慢了100倍😱。

一个分页统计条数的SQL,在遥遥领先的 服务器 执行 40毫秒,在国产环境竟然达到了 惊人的 10s💀!

SQL 优化过程

执行计划分析

  1. 执行计划不一样,国产环境高一个小版本的数据库,查询SQL 时做了三次嵌套,并且存在类型转换
  1. 瑶瑶领先环境的执行计划是这样的,明显SQL 进行了优化 left join 的C 表直接去掉了,所以只loop了两次

SQL 优化

  1. 优化类型转换

看到这儿,至少知道怎么优化了,第一 去掉类型的转换,把 is_del = 0 改成数据库的boolea类型,再看一下执行计划

现在是没有类型的转换了,并且 最里面的一层 loop 循环优化成了 Hash join

这时候 执行时间已经是 300ms 左右了。

2.SQL 优化:去掉left join C 表

接下来我们自定义一个 COUNT SQL 去掉C表的连接, 覆盖框架里面自动生成COunt sql 这样执行时间 就缩短到了 10ms 左右了。

因为 left join C 没有对C表进行任何过滤,并且不会存在一对多的情况,所以直接去掉C表的统计。

总结

本篇文章 通过Explain 分析SQL 的执行计划,定位到了SQL 执行缓慢的原因。 然后通过 覆盖 count 自动生成的SQL,从来减少连表查询。 最后将SQL的查询时间 从 10s 优化到了10ms,提升了1000倍🚀

我想不通的是,一个小的版本,居然执行计划相差这么大. 同时 数据量也不大,估计CPU 和 IO 的国产环境效率很低👎

推荐阅读:【hash join

推荐阅读:【类型转换之谜

相关推荐
雪域迷影20 分钟前
Go语言中通过get请求获取api.open-meteo.com网站的天气数据
开发语言·后端·http·golang·get
梦子yumeko1 小时前
第五章Langchain4j之基于内存和redis实现聊天持久化
数据库·redis·缓存
IndulgeCui2 小时前
【金仓数据库产品体验官】KSQL Developer Linux版安装使用体验
linux·运维·数据库
一马平川的大草原3 小时前
基于n8n实现数据库多表数据同步
数据库·数据同步·dify·n8n
于小汐在咯4 小时前
深入浅出:增强现实(AR)技术全解析
后端·ar·restful
爱上妖精的尾巴4 小时前
5-27 WPS JS宏数组元素添加删除应用2
后端·restful·wps·js宏
努力的小郑4 小时前
与产品经理的“模糊”对决:Elasticsearch实现MySQL LIKE '%xxx%' 的奇幻之旅
后端·elasticsearch·搜索引擎
老华带你飞4 小时前
商城推荐系统|基于SprinBoot+vue的商城推荐系统(源码+数据库+文档)
java·前端·数据库·vue.js·spring boot·毕设·商城推荐系统
一 乐4 小时前
物业管理系统|小区物业管理|基于SprinBoot+vue的小区物业管理系统(源码+数据库+文档)
java·前端·数据库·vue.js·spring boot·后端
稚辉君.MCA_P8_Java4 小时前
RocketMQ 是什么?它的架构是怎么样的?和 Kafka 又有什么区别?
后端·架构·kafka·kubernetes·rocketmq