来看！这才是久经沙场得 SQL 优化经验

跟着 SQL 优化得经验之谈，面试真的可以侃侃而谈。

那么面对复杂的关系数据，我们如何来优化，SQL如何玩转更优？

先抛出了4个关于优化方面的问题：

1.返回表中0.014%的数据应不应该走索引？

2.什么样的列必须建立索引呢？

3.嵌套查询、HASH连接、排序合并连接、笛卡尔连接等怎样玩能达到最优？

4.IN 与EXISTS 谁快谁慢？

整个优化内容篇幅过长，查询优化内容并非一篇文章就能讲明白，更多是需要自己的消化并通过实践运用来得出自己的一套优化体系。

文本也是分篇幅进行讲解，还需慢慢消化其中的内容，目前只针对上述的两个问题进行了解释，其余两个问题是关于连表查询的优化内容，将在下篇的sql连接查询优化进行细谈。

相关的优化知识和经验，也是本人通过自身的学习并通过实践运用，不免存在一定的偏差和错误，如有大佬指正以及其他方面的分享，不甚感激。

SQL简单查询

SQL简单查询

简单查询格式如下：

SELECT * FROM 表名 WHERE 条件 SELECT 字段原名 AS 字段别名

选择条件的构成： =(等于)、<>(不等于)、<(小于)、>(大于)、<=(不大于)和>=(不小于)

优先级：

NOT优先级高于AND，AND的优先级高于OR。注意使用圆括号的使用。

涉及空值的查询：空值用NULL表示，表明空值或者不为空值可以用“IS NULL”或 “IS NOT NULL”

字符串的比较：

SQL的习惯用法是在 % 和 _ 之前加上转义符号“\”表示这里的 % 和 _ 是一个普通的字符，而不是匹配使用。如果不把 \ 作为转义符号，只把它当作一个普通字符，可以连续两个 \ 表示一个真正的反斜线 \。

输出的排序：

ORDER BY <字段名> ，提示：默认排序是升序（ASC），可用倒叙（DESC）

聚合运算符：

SUM：求某列中所有值的和；

AVG：求某列中所有值的平均值；

MIN：求某列中的最小值；

MAX：求某列中的最大值；

COUNT：求某列中值的个数。

分组：

在WHERE子句加上GROUP BY ，关键字GROUP BY 后面给出分组属性列表。

注：如果只希望查询满足一定条件的分组情况，可以使用关键字HAVING来选择具有给定条件的分组。

sql优化

在谈及sql查询优化，优化性能是每个优秀的工程师必备的思想之一，无论是面对复杂还是简单的工程不仅仅满足于表现层的结果，哪怕你优化的速度提高了百分之一，都是经历过自己思考的过程，以及走向成熟的过程。

再谈优化之前，先掌握几个重要的概念：基数，选择性，直方图，回表，集群因子，表关系。

基数：某个列唯一键（Distinct_Keys）的数量叫作基数。比如性别列，该列只有男女之分，所以这一列基数是2。主键列的基数等于表的总行数。

例如：select count(distinct name), count(distinct age), count(*) from student 语句查询如下：

count(distinct name)	count(distinct age)	count(*)
76	34	86

学生当中不重复的名字有76，年龄34，学生人数为86。

基数的高低影响列的数据分布，往往基数高的列通常用作索引，获取数据的命中率高。

那么，回到上面的第一个问题：返回表中0.014%的数据应不应该走索引？

在数据足够多，达到百万千万级的数据时，当查询结果是返回表中5%以内的数据时，应该走索引；当查询结果返回的是超过表中5%的数据时，应该走全表扫描。

也就是说，如果某个列基数很低，该列数据分布就会非常不均衡，由于该列数据分布不均衡，会导致SQL查询可能走索引，也可能走全表扫描。在做 SQL优化的时候，如果怀疑列数据分布不均衡，我们可以使用select列，count(*) from 表 group by 列 order by desc来查看列的数据分布。

选择性：一个操作过滤的记录的比例，是一个介于 0 和 1 之间的数值。通常工程师在使用查表时，往往会筛选掉不必要的数据列来提高查询速率，这也是一种很直观的优化方式。那么在数据重量级的情况下，我们要怎么来直观的查看选择性呢？通常，基数与总行数的比值再乘以100%就是某个列的选择性。

那么，我们可以回到上述的第二个问题：什么样的列必须建立索引呢？

在我的之前建立索引的经验中，往往基数高的列，where条件中常用的列来建立索引，但是这样往往还不够，我们无法单一的看基数高的列，where常用条件就来建立索引，此时我们无法确定命中率的高低，所以，通过基数与总行数的比值再乘以100%，就能直观的看出哪些列占比就可以建立索引。当一个列选择性大于20%，说明该列的数据分布就比较均衡了。

直方图：如果没有对基数低的列收集直方图统计信息，基于成本的优化器（CBO）会认为该列数据分布是均衡的。

1.如果没有对基数低的列收集直方图统计信息，基于成本的优化器（CBO）会认为该列数据分布是均衡的。

2.直方图信息就是以上SQL的查询结果，这些查询结果会保存在数据字典中。这样当我们查询owner为任意值的时候，CBO总会算出正确的Rows，因为直方图已经知道每个值有多少行数据。

以pgsql 为例：

也就是说，你所执行的sql查询之后，你所查询的结果会保存在数据字典中，这里也涉及到了数更新之后所统计的数据没有更新的话会存在一定的误差，这也是后话了。

如果SQL使用了绑定变量，绑定变量的列收集了直方图，那么该SQL就会引起绑定变量窥探。关于绑定变量窥探的问题，这里也不过多讲诉。

那，什么样的列需要收集直方图呢？

当列出现在where条件中，列的选择性小于1%并且该列没有收集过直方图，这样的列就应该收集直方图。注意：千万不能对没有出现在where条件中的列收集直方图。对没有出现在where条件中的列收集直方图完全是做无用功，浪费数据库资源。

回表：当对一个列创建索引之后，索引会包含该列的键值以及键值对应行所在的rowid。通过索引中记录的rowid访问表中的数据就叫回表。回表一般是单块读，回表次数太多会严重影响SQL性能，如果回表次数太多，就不应该走索引扫描了，应该直接走全表扫描。

为什么返回表中5%以内的数据走索引、超过表中5% 的数据走全表扫描？

根本原因就在于回表。在无法避免回表的情况下，走索引如果返回数据量太多，必然会导致回表次数太多，从而导致性能严重下降。

什么样的SQL必须回表？什么样的不需要回表呢？

select *from tablename where ......

这样的sql是必须回表的，所以工程师们在编写sql的时候通常严禁 select * 的出现。

select count(*) from tablename .

这样的sql就不走回表，当查询的列也包含在索引中时，也不需要走回表，所以通常建立索引时，往往会建立组合索引来消除回表，来提升性能。

集群因子：集群因子用于判断索引回表需要消耗的物理I/O次数。上面我们提到，回表是走单块读取，每一条数据的回表它都是一次IO消耗。

1.集群因子的算法，在这我们暂且先不提，但是我们知道集群因子介于表的块数和表行数之间。

2.如果集群因子与块数接近，说明表的数据基本上是有序的，而且其顺序基本与索引顺序一样。这样在进行索引范围或者索引全扫描的时候，回表只需要读取少量的数据块就能完成。

3.如果集群因子与表记录数接近，说明表的数据和索引顺序差异很大，在进行索引范围扫描或者索引全扫描的时候，回表会读取更多的数据块。

集群因子只会影响索引范围扫描（INDEX RANGE SCAN）以及索引全扫描（INDEX FULL SCAN），因为只有这两种索引扫描方式会有大量数据回表。集群因子不会影响索引唯一扫描（INDEX UNIQUE SCAN），因为索引唯一扫描只返回一条数据。集群因子更不会影响索引快速全扫描（INDEX FAST FULL SCAN），因为索引快速全扫描不回表。

集群因子究竟影响的是什么性能呢？

集群因子影响的是索引回表的物理I/O次数。我们假设索引范围扫描返回了1 000行数据，如果buffer cache(缓存)中没有缓存表的数据块，假设这1000行数据都在同一个数据块中，那么回表需要耗费的物理I/O就只需要一个；假设这1000行数据都在不同的数据块中，那么回表就需要耗费1000个物理 I/O。因此，集群因子影响索引回表的物理I/O次数。

请注意，不要尝试重建索引来降低集群因子，这根本没用，因为表中的数据顺序始终没变。唯一能降低集群因子的办法就是根据索引列排序对表进行重建（create table new_table as select * from old_table order by 索引列），但是这在实际操作中是不可取的，因为我们无法照顾到每一个索引。