一次非常有意思的SQL优化经历:从30248.271s到0.001s
一、背景介绍
用的数据库是mysql5.6，下面简单的介绍下场景
课程表：
数据100条
学生表：
数据70000条
学生成绩表SC：
数据70w条
查询目的：
二、问题：查找语文考100分的考生
查询语句：
执行时间：30248.271s
为什么这么慢？先来查看下查询计划：
发现没有用到索引，type全是ALL，那么首先想到的就是建立一个索引，建立索引的字段当然是在where条件的字段。
先给sc表的c_id和score建个索引
再次执行上述查询语句，时间为: 1.054s
快了3w多倍，大大缩短了查询时间，看来索引能极大程度的提高查询效率，看来建索引很有必要，很多时候都忘记建索引了，数据量小的的时候压根没感觉，这优化感觉挺爽。
但是1s的时间还是太长了，还能进行优化吗，仔细看执行计划：
查看优化后的sql:
补充：这里有网友问怎么查看优化后的语句
方法如下：
在命令窗口执行
有type=all
按照我之前的想法，该sql的执行的顺序应该是先执行子查询
耗时：0.001s
得到如下结果：
然后再执行
耗时：0.001s
这样就是相当快了啊，Mysql竟然不是先执行里层的查询，而是将sql优化成了exists子句，并出现了EPENDENT SUBQUERY，
mysql是先执行外层查询，再执行里层的查询，这样就要循环70007*11=770077次。
那么改用连接查询呢？
这里为了重新分析连接查询的情况，先暂时删除索引sc_c_id_index，sc_score_index
执行时间是：0.057s
效率有所提高，看看执行计划：
这里有连表的情况出现，我猜想是不是要给sc表的s_id建立个索引
CREATE index sc_s_id_index on SC(s_id);
show index from SC
在执行连接查询
时间: 1.076s，竟然时间还变长了，什么原因？查看执行计划：
优化后的查询语句为：
貌似是先做的连接查询，再执行的where过滤
回到前面的执行计划：
这里是先做的where过滤，再做连表，执行计划还不是固定的，那么我们先看下标准的sql执行顺序：
苦逼的码农注：知道执行顺序是非常重要的，建议通过这张表熟悉一下，最后不要死记硬背，而是理解他们。
正常情况下是先join再where过滤，但是我们这里的情况，如果先join，将会有70w条数据发送join做操，因此先执行where过滤是明智方案，现在为了排除mysql的查询优化，我自己写一条优化后的sql
即先执行sc表的过滤，再进行表连接，执行时间为：0.054s
和之前没有建s_id索引的时间差不多
查看执行计划：
先提取sc再连表，这样效率就高多了，现在的问题是提取sc的时候出现了扫描表，那么现在可以明确需要建立相关索引
再执行查询：
执行时间为：0.001s，这个时间相当靠谱，快了50倍
执行计划：
我们会看到，先提取sc，再连表，都用到了索引。
那么再来执行下sql
执行时间0.001s
执行计划：
这里是mysql进行了查询语句优化，先执行了where过滤，再执行连接操作，且都用到了索引。
总结
1、mysql嵌套子查询效率确实比较低
2、可以将其优化成连接查询
3、建立合适的索引
4、学会分析sql执行计划，mysql会对sql进行优化，所以分析执行计划很重要。
来源：toutiao.com/i6668275333034148356
作者：Java技术架构
本文为 @ 21CTO 创作并授权 21CTO 发布，未经许可，请勿转载。
内容授权事宜请您联系 webmaster@21cto.com或关注 21CTO 公众号。
该文观点仅代表作者本人，21CTO 平台仅提供信息存储空间服务。
评论
21CTO
管理团队最新文章
Node.js 作者再次喊话 Oracle：...
11月29日为什么大家都在使用 PostgreSQL...
11月28日Rust将如何改变机器人技术？
11月28日
实例展示Java、Python、PHP在移...
09月23日人工智能业务疯长，亚马逊超越AW...
11月27日滴滴张博卸任CTO，将专注自动驾...
11月27日10 倍开发人员与人工智能：精英...
11月25日OpenAI 宣布面向开发人员的新功...
11月25日最佳开源 IDE 盘点
11月25日瑞士在历史悠久的教堂里实现了一...
11月25日美国司法部将迫使谷歌出售 Chrom...
11月21日2025 年十大现代 JavaScript 模...
11月21日Chrome 是新的 IE 吗？
11月20日