SQL优化实操案例：如何拯救龟速SQL

   精心准备的运营活动，准备通过某节点吸引一些用户量，活动一开始，后端数据大屏显示一批用户拥挤进来，到最终提交信息的寥寥无几，“此时办公区交流完全靠吼，怎么只有这几个用户，哪里发生问题了，快看看怎么回事。。。”

   一顿操作猛如虎，一条龟速SQL是这场事故的终极BOSS，让我们来看看究竟怎么一回事

解剖

运行耗时：10.72 sec

• 执行计划
  

t表全面扫描行数较大、用到临时表、文件排序

tc表扫描行数较大

化验

• t表354724行

• tc表3018991行 

• where条件未做前置过滤

治疗

• 缩小结果

• 治疗结果
  

效率不如从前

主要tc表扫描行数据更多导致

• 全力治疗tc
  

添加索引

ALTER TABLE tunnel_connection ADD KEY tunnel_code(online,tunnel_code)

• 治疗结果
  

运行耗时：1.01sec

拯救秘籍

• 主要tunnel_connection 表缺少合理索引

• tunnel_code单列索引，修改为（online，tunnel_code）复合索引

• 并通过改写缩小t表结果集

  
  

往期回顾

热文

union all 语句该如何优化？

丨更多

围观

SQL优化必懂概念

丨更多

^{本文分享内容是我自己的一些见解，欢迎大家一起来评论留言探讨，我会不定期更新内容，大家可以关注我哟~，也可以在今日头条搜索“青雨果果”关注我！~}

青雨果果

没时间解释了，快长按左边二维码关注我们～～