共计 3588 个字符，预计需要花费 9 分钟才能阅读完成。
本篇内容介绍了“关于 SQL 的优化有哪些”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让丸趣 TV 小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！
大部分人说的 SQL 优化
阿粉之前帮公司面试过一部分人，因为之前和老大一起面试，所以也看过不少人的简历，而简历上对于数据库这块内容，很多人都写的是这个样子的。
熟练使用 MySQL，SQLServer，熟悉 Oracle，熟悉 SQL 语句优化。
确实，如果你对数据库没有进行过深入的了解的时候，你也不敢往上面写，只能是去写关于 SQL 语句优化方面的，但是很多时候，在你写完这个 SQL 语句之后，你是压根不会去主动的去优化的，很多时候都是停在了，不出问题，我就不改，只要功能实现了，那么，一切万事大吉。
而本文，告诉你，不要只是会 SQL 语句优化。
SQL 语句优化我们在面试的时候，面试官看你写了 SQL 语句优化，有时候就会提问了，那你说说 SQL 语句优化都是在哪些方面的吧。
关于 SQL 语句优化，内容可就比较多了。
对查询进行优化，应尽量避免全表扫描，首先应考虑在 where 及 order by 涉及的列上建立索引。
尽量避免在 where 子句中使用!= 或 操作符，否则将引擎放弃使用索引而进行全表扫描。
应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描。
。。。。。
类似这样的 SQL 语句优化还有很多很多，但是大家有没有注意到我在上面标注出来的内容，引擎? 相信大家之前肯定也都知道，但是没有做过多的研究，但是为了各位面试顺利，我们就来加紧分析这个吧。
MySQL 体系以下全文，全部按照 MySQL 来进行分析，分析引擎，我们先从 MySQL 分析吧。MySQL 的体系结构图如下：
我们能从图中看出一点内容，比如说 MySQL 的组成部分。
连接池组件
管理服务和工具组件
SQL 接口组件
查询分析器组件
优化器组件
缓冲 (Cache) 组件
插件式存储引擎
物理文件
不得不说，这个插件式存储引擎总结的是极其精辟的呀，MySQL 数据库区别于其他数据库的最重要的一个特点就是其插件式的表存储引擎。
但是我们要注意一个最重要的，那就是存储引擎是基于表的，而不是数据库。
MySQL 存储引擎
存储引擎是 MySQL 区别于其他数据库的一个最重要特性，每个存储引擎都有他们自己的特点，不同的特点，会在不同的场景下使用，虽然我们在开发中很多时候都是使用的一种，但是能够根据具体的应用建立不同存储引擎表，这才是最牛逼的吧。
那么我们看看 MySQL 都支持哪些存储引擎把，手动在自己的 MySQL 中输入查询语句 show engines, 就会如下图所示。
大家看完是不是感觉还挺多，但是 MySQL 的 9 种存储引擎都是各自是各自的特点，然后根据需求的不同，我们在建表的时候可以选择一下，是不是发现了又一个带妹的好机会，那我们就开始分析一下吧。
1.FEDERATED 存储引擎
在阿粉之前翻看书籍的时候就看到过这个，说这个引擎不是存放数据的引擎，而是一个指向远程 MySQL 数据库服务器的，那是什么意思呢，其实一句大白话：“我这里不存表结构文件和数据文件，我是在远程端存的”，这时候就有了个比较有意思的地方，如下图：
就像图上说的，FEDERATED 存储引擎分成了 2 部分，一部分是本地服务，另外一部分就是远程服务，那么如果在你切换到这个引擎的时候，他在执行 CRUD 的时候，就会把执行操作的命令发到远程服务器，然后执行完了之后，在发回本地，然后从本地服务器中返回匹配的行即可。
在这里，阿粉不去着重的讲这个，因为重点是我们最常使用的那个，大家肯定都知道，那就是 InnoDB 存储引擎。
2.InnoDB 存储引擎
InnoDB 存储引擎这个一般也是大家在面试中经常的能和面试官侃侃而谈的一个，因为它是默认的数据库存储引擎。注意，这个默认是从 MySQL 的 5.5.8 开始的
特点比较多，下面就开始分析一下都有哪些特点吧。
支持事务。默认的事务隔离级别为可重复，这个我们经常用，所以肯定也都知道。
支持外键，这个外键大家肯定也都清楚，有利有弊，毕竟外键的作用在那里放着(利：增加可读性，若出现宕机，最大限度的保证数据的一致性和完整性，弊：降低了表的查询速度，如果数据了过大，那么你插入数据库数据的时长可能是不增加外键的十倍)
行锁设计，这样可以支持更高的并发，这也是为什么有时候面试官说你们上 ES 有点大材小用，因为 MySQL 自己也能处理那么多。
使用多版本并发控制 (MVCC) 来获得高并发性，并且实现了 SQL 标准的 4 种隔离级别，默认为 REPEATABLE READ 级别。
使用一种被称为 next-key locking(有人称它为间隙锁)的策略来避免幻读 (phantom) 现象的产生
数据存储采用了聚集 (clustered) 的方式，每张表的存储都是按主键的顺序进行存放。
InnoDB 的索引结构和 MySQL 其他的存储引擎不同，聚簇索引对主键查询性能非常高，这时候就得有个限制要求，如果表上的索引较多，主键就尽可能的小。
InnoDB 通过一些机制和工具都支持真正的热备份，也就是在线热备份。
数据存储在表空间 (tablespace) 中，这个表空间实际上是由 InnoDB 管理的一个黑盒，由一系列的文件组成。
2.1InnoDB 的体系架构
我们从上面的图中就能看到，InnoDB 存储引擎有许多的内存块，可以认为这些内存块其实就相当于是一个大的内存池，就是线程池是类似的那种，
既然图中我们看到了后台的线程，那么我们也要说说这个后台线程是个什么?
InnoDB 存储引擎是多线程的模型，因此其后台有多个不同的后台线程，负责处理不同的任务。
而这个后台线程也是分两个部分的，一个是核心线程，一个是 IO 线程。
核心线程 Master Thread
IO 线程 IO Thread
净化线程 Purge Thread
清理线程 Page Cleaner Thread
核心线程
核心线程的作用就是将缓冲池中的数据异步的刷新到磁盘上，来保证数据的一致性。
IO 线程
IO 线程则很简单，主要就是用来 IO 请求的回调处理。
净化线程
主要作用就是事务提交之后回收已经使用并分配的 undo 页
清理线程
他的作用是将之前版本中脏页的刷新操作都放入到单独的线程中来完成。
如果阿粉当时面试的时候能够把这些内容给面试官说上，相信工资肯定还能再多来点。
3.Memory 存储引擎
Memory 存储引擎实际上就是将表中的数据存放在内存中，如果数据库重启或发生崩溃，表中的数据都将消失。也就是说，如果你们的数据存储在 Memory 存储引擎中，如果机房不慎掉电，那完了，之前存在里面的东西都没了，就和你用了个 rm -rf 效果一样，不过一个是被动的，一个是主动的。
这种用的比较少，阿粉就不再多给大家介绍了，就说说它的特点得了，毕竟一个关机，直接就没了。
不支持 TEXT 和 BLOB 类型，对于字符串类型的数据，只支持固定长度的行，VARCHAR 会被自动存储为 CHAR 类型;
速度非常快，只支持表锁，并发性能较差，并且不支持 TEXT 和 BLOB 列类型
服务器一但出现宕机，所有数据全部消失
存储变长字段 (varchar) 时是按照定常字段 (char) 的方式进行的，因此会浪费内存
4.MyISAM 存储引擎
这个引擎特点非常明显，不支持事务，但是支持全文检索，要面向一些 OLAP(联机分析处理)数据库应用.
5.BLACKHOLE 存储引擎
这个引擎就像他的名字一样，肉包子打狗，有去无回，它的用途也比较简单
SQL 文件语法的验证
用来查找与存储引擎自身不相关的性能瓶颈
6.CSV 存储引擎
CSV 存储引擎实际上操作的就是一个标准的 CSV 文件，而且他的特点就是不支持索引，也就说，不支持索引，那么效率必然会很低，这个相信很多人都不会选择去使用它。
针对这些引擎，阿粉就说，既然都了解了这么多的内容了，那肯定不能在继续说我们的 SQL 语句优化了，当你在面试的时候，就要有针对性的了。
假如说面试的时候，面试官问你：现在有一个功能，测试那边反馈过来的信息是，这个功能的响应时间超出了预期的值，你都从哪些方面入手来处理这个问题。
这个问题看似不是很难，但是可以根据这个问题延伸出很多很多的问题。
问题一：如果你说从 SQL 语句优化，入手，那么势必要去检查索引，而面试官下一个问题可能就是，为什么加了索引，速度就会变快。
问题二：如果你说服务器的配置，那么面试官可能心里就想，为了一个功能上的反馈，你让我去给服务器增加配置，代价太大。
如果你对索引还没有了解到很深层面的时候，这个时候你就可以把 SQL 语句优化，和看数据库该表的引擎是否可以进行修改，如果可以，那么你就可以开始把这些关于 SQL 引擎的优势往自己的方向走了。
“关于 SQL 的优化有哪些”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注丸趣 TV 网站，丸趣 TV 小编将为大家输出更多高质量的实用文章！
