首页
学习
活动
专区
工具
TVP
发布

MySQL之SQL优化实战记录

作者:小祝特烦恼

来自:https://my.oschina.net/xiaozhutefannao/blog/2243432

背景

本次SQL优化是针对javaweb中的表格查询做的。

部分网络架构图

业务简单说明

N个机台将业务数据发送至服务器,服务器程序将数据入库至MySQL数据库。服务器中的javaweb程序将数据展示到网页上供用户查看。

原数据库设计

windows单机主从分离

已分表分库,按年分库,按天分表

每张表大概20w左右的数据

原查询效率

3天数据查询70-80s

目标

3-5s

业务缺陷

无法使用sql分页,只能用java做分页。

问题排查

前台慢 or 后台慢

如果你配置了druid,可在druid页面中直接查看sql执行时间和uri请求时间

在后台代码中用System.currentTimeMillis计算时间差。

结论 : 后台慢,且查询sql慢

sql有什么问题

sql拼接过长,达到了3000行,有的甚至到8000行,大多都是union all的操作,且有不必要的嵌套查询和查询了不必要的字段

利用explain查看执行计划,where条件中除时间外只有一个字段用到了索引

备注 : 因优化完了,之前的sql实在找不到了,这里只能YY了。

查询优化

去除不必要的字段

效果没那么明显

去除不必要的嵌套查询

效果没那么明显

分解sql

将union all的操作分解,例如(一个union all的sql也很长)

将如上sql分解成若干个sql去执行,最终汇总数据,最后快了20s左右。

将分解的sql异步执行

利用java异步编程的操作,将分解的sql异步执行并最终汇总数据。这里用到了CountDownLatch和ExecutorService,示例代码如下:

结果又快了20-30s

优化MySQL配置

以下是我的配置示例。加了skip-name-resolve,快了4-5s。其他配置自行断定

根据业务,再加上筛选条件

快4-5s

将where条件中除时间条件外的字段建立联合索引

效果没那么明显

将where条件中索引条件使用inner join的方式去关联

针对这条,我自身觉得很诧异。原sql,b为索引

应该之前有union all,union all是一个一个的执行,最后汇总的结果。修改为

结果快了3-4s

性能瓶颈

根据以上操作,3天查询效率已经达到了8s左右,再也快不了了。查看mysql的cpu使用率和内存使用率都不高,到底为什么查这么慢了,3天最多才60w数据,关联的也都是一些字典表,不至于如此。继续根据网上提供的资料,一系列骚操作,基本没用,没辙。

环境对比

因分析过sql优化已经ok了,试想是不是磁盘读写问题。将优化过的程序,分别部署于不同的现场环境。一个有ssd,一个没有ssd。发现查询效率悬殊。用软件检测过发现ssd读写速度在700-800M/s,普通机械硬盘读写在70-80M/s。

优化结果及结论

优化结果:达到预期。

优化结论:sql优化不仅仅是对sql本身的优化,还取决于本身硬件条件,其他应用的影响,外加自身代码的优化。

小结

优化的过程是自身的一个历练和考验,珍惜这种机会,不做只写业务代码的程序员。希望以上可以有助于你的思考,不足之处望指正。如转载,请标明作者。

●编号430,输入编号直达本文

●输入m获取文章目录

推荐↓↓↓

Web开发

更多推荐《18个技术类微信公众号》

涵盖:程序人生、算法与数据结构、黑客技术与网络安全、大数据技术、前端开发、Java、Python、Web开发、安卓开发、iOS开发、C/C++、.NET、Linux、数据库、运维等。

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20181018B0RZX600?refer=cp_1026
  • 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码

添加站长 进交流群

领取专属 10元无门槛券

私享最新 技术干货

扫码加入开发者社群
领券