一句慢 SQL 执行 600 秒?!你咋不上天呢

大家好,我是程序员鱼皮。最近看了眼我们数据库的监控,属实被吓到了,竟然有这么多慢 SQL!

其中,有一条慢 SQL 更是逆天,执行了 600 多秒?!

看到这,我当时就是这表情:

如果不是我有看监控的意识,估计这种慢 SQL 还在持续拖慢我们的数据库和项目,我团队的后端朋友们还需要锻炼锻炼呀!

借这个机会,给大家分享一点儿慢 SQL 优化的知识。

什么是慢 SQL?

先解释一下,慢 SQL 指的是执行时间较长的 SQL 查询或操作。它不是一个固定的时间定义,而是根据具体的应用场景和性能要求来决定。

比如你要从几万条数据中查出某一条数据,超过几百毫秒就已经算是慢 SQL 了;但如果你要向数据库插入几万条数据,可能几十秒都不算是慢 SQL。慢是相对的,没有固定的标准。

某种情况下,也可以将消耗数据库资源过多的 SQL 归纳为慢 SQL,因为它们的危害是一样的:都会增加数据的负载、降低数据库的响应速度,有些慢 SQL 还可能导致数据库的锁被占用,从而影响到整个数据库的性能。

所以一般情况下,我们要定期检查数据库中的慢 SQL。

如何检测分析慢 SQL?

“如何检测分析慢 SQL” 也是一道经典的面试题了,对于 MySQL 来说,可以分析 MySQL 自带的慢查询日志、通过 Explain 查看 SQL 的执行计划、通过 Profiling 分析 MySQL 查询的详细执行信息等。

不过俗话说得好,面试造火箭,工作拧螺丝。

一般有些规模的公司都会有自己的慢 SQL 收集分析平台,哪还需要自己敲命令呢?像我们鱼厂虽然是小公司,也可以用大公司提供的云服务呀!慢日志监控、告警、甚至是优化建议,都帮忙做好了,直接使用美滋滋~

如何优化慢 SQL?

下面就以这句最大执行了 600 多秒的坑爹小 SQL 为例,简单聊一下怎么优化。

这条 SQL 的作用是查询指定权限的用户在某段时间内发送的消息记录。由于消息记录表(message_record)和用户表(user)的数据量都非常大,再加上有关联查询,导致查询缓慢。

如图,执行 600 多秒的 SQL 扫描了 600 多万行数据:

这句 SQL 怎么优化呢?

先看这句 SQL 的写法,其实没有什么大问题。虽然确实可以做一些小的改动,比如把 left join 改成 inner join、或者用用子查询之类的,但是优化效果并不明显。

那下一步,就是掏出数据库优化大杀器 —— 索引 ,从相关面试题的数量,就已经能感受到索引的重要性了。


其实我用的数据库监控平台已经给出了优化建议,正是添加索引:

添加索引最简单的原则就是:需要根据什么字段查询 / 排序 / 连接 / 分组,就可以考虑增加索引。当然,具体情况具体分析,索引的选择需要根据查询条件、表的大小、数据分布等多方面考虑,比如字段值是唯一的、或者值比较分散的字段更适合加索引,而不建议给性别这种值区分度不高的字段增加索引。

所以对于这句慢 SQL,我选择给 message_record 表的 createTime 字段增加索引,然后使用 Explain 语句查看执行计划,会利用到新增的索引:

该加的索引已经加了,但因为主表和子表的数据量就是比较大,查询还是巨慢,怎么办呢?这种情况下,可以先思考能否 先通过业务手段解决 。既然优化不了它,那就干掉它!思考:这句 SQL 能不能不执行?为什么要同时查出这么多用户的消息记录?是不是需求本身就不合理?

如果你把产品经理说服了,OK,愉快摸鱼。

但如果产品经理把你说服了,好吧,那就再考虑下 能不能通过程序优化 ?比如将查询进行拆分,按照更精确的日期(比如 “天”)多次查询消息、或者指定用户 id 来避免联表查询,并且通过多线程同时并发执行查询。当然这样是否有效还是需要验证的。

还有其他的方法:

1)如果查询是需要频繁(或实时)触发的,可以使用 Redis 或内存来缓存数据,避免重复查库。

2)如果查询是定时触发的,可以考虑降低定时任务的执行频率,并且尽量错峰查询,避免这种慢 SQL 在用户使用高峰期执行。

大家看图也能够发现,我们的慢 SQL 主要就是在凌晨出现的,这是由于凌晨用户比较少,我们选择在这个时间点执行一些比较重的定时任务。

如果无法通过程序优化,那么就从数据库下手吧,比如通过分库分表,将消息记录表按天拆分成多个表,提高单表查询效率;或者将已经被逻辑删除的消息移动到另一张表中进行备份,而不是继续存在于主表中,跟清空电脑上的回收站是类似的道理。但分库分表的代价就是有额外的实现成本和维护成本,建议还是慎用。

还有其他的优化方法,比如升级数据库的配置,甚至是更换一个查询性能更高的数据库(比如适用于大数据分析的 ClickHouse),不过成本有点高,反正对于我们小公司百万量级的数据量来说,还没必要考虑。


以上就是本期分享,大家平时自己写项目的时候可能不太注意 SQL 的写法,觉得项目能跑就行。但其实学习 SQL 优化是很有必要的,因为等你进公司后随着业务数据量的增大,有些慢 SQL 会逐渐暴露出问题。不是不报,时候未到而已。

👇🏻 点击下方阅读原文,获取鱼皮往期编程干货。


往期推荐

又一个新项目完结,炸裂!

秋招提前批,出成果了!

突发,众多网站流量被盗刷!我特么也中招了

万万没想到,一张图片也能引发网站崩溃!

秋招背八股文,用这个神器就够了

编程导航,即将大升级!

保姆皮的写简历指南,免费看!

相关推荐

  • 一次事故暴露出的三个架构问题
  • 徐峥演出了人间真实:面对裁员,hr说人家能熬啊
  • 基于趋势和季节性的时间序列预测实战
  • 没有千亿级也没有百亿级,ToB 大模型如何挖掘不足 1% 的企业数据的价值?
  • vivo蓝河操作系统首届技术沙龙即将举办,邀您共探Rust与AI新时代!| Q推荐
  • K8s 技术人不得不说的考证二三事 | 极客时间
  • 清华大学汪玉:大模型能效提升,有几条必经之路?
  • 软件工程的兴衰轮回:2 年巨变,裁员风暴下小团队逆袭,老技术反迎第二春?
  • 招聘|Anytime AI-机器学习工程师
  • 资料下载:《大语言模型实战宝典》
  • 弱监督建模技术在蚂蚁风控场景中的探索与应用
  • 2024年云中AI工程的三大关键趋势
  • 关于攻防演练,90%企业不知道的3个真相
  • 烧钱抢老司机饭碗?“萝卜快跑”事件辟谣:武汉仅投放400多辆无人车;“萝卜”相关负责人揭秘AI新职业:“云代驾”!
  • 北京内推 | ​度小满金融AI LAB招聘数字人/文生视频方向研究型实习生
  • 当Mamba遇上视觉压缩:首个具有选择性状态空间的视觉压缩网络
  • 生成式模型不只会「模仿」!哈佛、UCSB等最新成果:性能可超越训练集专家水平
  • 斯坦福炒虾机器人原班人马新作!最强大脑Gemini加持,机器人炫技导航玩出新花样
  • OpenAI机密五级AGI路线图曝光!GPT-4仍处L1,内部AI接近博士水平18个月诞生
  • Mamba一作再祭神作,H100利用率飙至75%!FlashAttention三代性能翻倍,比标准注意力快16倍