Join关联查询优化

用心去追梦

于 2024-01-18 20:52:01 发布

阅读量954

点赞数 23

文章标签：数据库

本文链接：https://blog.csdn.net/qq_33240556/article/details/135683940

版权

准备数据


-- 示例表：
CREATE TABLE `t1` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `a` int(11) DEFAULT NULL,
  `b` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `idx_a` (`a`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

create table t2 like t1;

-- 往t1表插入1万行记录
DROP PROCEDURE
IF
	EXISTS insert_t1;

delimiter;;
CREATE PROCEDURE insert_t1 () BEGIN
	DECLARE
		i INT;
	
	SET i = 1;
	WHILE
			( i <= 100000 ) DO
			INSERT INTO t1 ( a, b )
		VALUES
			(i, i );
		
		SET i = i + 1;
		
	END WHILE;
	
END;;

delimiter;
CALL insert_t1 ();

-- 往t2表插入100行记录
DROP PROCEDURE
IF
	EXISTS insert_t2;

delimiter;;
CREATE PROCEDURE insert_t2 () BEGIN
	DECLARE
		i INT;
	
	SET i = 1;
	WHILE
			( i <= 100 ) DO
			INSERT INTO t2 ( a, b )
		VALUES
			(i, i );
		
		SET i = i + 1;
		
	END WHILE;
	
END;;

delimiter;
CALL insert_t2 ();

mysql的表关联常见有两种算法

Nested-Loop Join 算法(NLJ)
Block Nested-Loop Join 算法(BNL)

2.1、嵌套循环连接 Nested-Loop Join(NLJ) 算法

一次一行循环地从第一张表（称为驱动表）中读取行，在这行数据中取到关联字段，根据关联字段在另一张表（被驱动表）里取出满足条件的行，然后取出两张表的结果合集。

#t2是驱动表，t1是被驱动表
#扫描了100+1000 = 200次
EXPLAIN select * from t1 inner join t2 on t1.a= t2.a;

从执行计划中可以看到这些信息：

驱动表是 t2，被驱动表是 t1。先执行的就是驱动表(执行计划结果的id如果一样则按从上到下顺序执行sql)；优化器一般会优先选择**小表做驱动表，**用where条件过滤完驱动表，然后再跟被驱动表做关联查询。所以使用 inner join 时，排在前面的表并不一定就是驱动表。
当使用left join时，左表是驱动表，右表是被驱动表，当使用right join时，右表时驱动表，左表是被驱动表，当使用join时，mysql会选择数据量比较小的表作为驱动表，大表作为被驱动表。

left join

#t2是驱动表，t1是被驱动表
#扫描了100+1000 = 200次
EXPLAIN select * from t1 inner join t2 on t1.a= t2.a;

使用了 NLJ算法。一般 join 语句中，如果执行计划 Extra 中未出现 Using join buffer 则表示使用的 join 算法是 NLJ。

上面sql的大致流程如下：

从表 t2 中读取一行数据（如果t2表有查询过滤条件的，用先用条件过滤完，再从过滤结果里取出一行数据）；
从第 1 步的数据中，取出关联字段 a，到表 t1 中查找；
取出表 t1 中满足条件的行，跟 t2 中获取到的结果合并，作为结果返回给客户端；
重复上面 3 步。

整个过程会读取 t2 表的所有数据(扫描100行)，然后遍历这每行数据中字段 a 的值，根据 t2 表中 a 的值索引扫描 t1 表中的对应行(扫描100次 t1 表的索引，1次扫描可以认为最终只扫描 t1 表一行完整数据，也就是总共 t1 表也扫描了100行)。因此整个过程扫描了** 200 行**。
如果被驱动表的关联字段没索引，使用NLJ算法性能会比较低(下面有详细解释)，mysql会选择Block Nested-Loop Join算法。

2.2、基于块的嵌套循环连接 Block Nested-Loop Join(BNL)算法

把驱动表的数据读入到 join_buffer 中，然后扫描被驱动表，把被驱动表每一行取出来跟 join_buffer 中的数据做对比。

#t2是驱动表，t1是被驱动表 
#扫描了100+1000 = 10100次
EXPLAIN select * from t1 inner join t2 on t1.b= t2.b;

Extra 中的Using join buffer (Block Nested Loop)说明该关联查询使用的是 BNL 算法。
上面sql的大致流程如下：

把 t2 的所有数据放入到** join_buffer** 中
把表 t1 中每一行取出来，跟 join_buffer 中的数据做对比
返回满足 join 条件的数据

1、整个过程对表 t1 和 t2 都做了一次全表扫描，因此扫描的总行数为10000(表 t1 的数据总量) + 100(表 t2 的数据总量) = 10100。
2、并且 join_buffer 里的数据是无序的，因此对表 t1 中的每一行，都要做 100 次判断，所以内存中的判断次数是 100 * 10000= 100 万次。
3、这个例子里表 t2 才 100 行，要是表 t2 是一个大表，join_buffer 放不下怎么办呢？·
join_buffer 的大小是由参数 join_buffer_size 设定的，默认值是 256k。如果放不下表 t2 的所有数据话，策略很简单，就是分段放。
比如 t2 表有1000行记录，join_buffer 一次只能放800行数据，那么执行过程就是先往join_buffer 里放800行记录，然后从 t1 表里取数据跟 join_buffer 中数据对比得到部分结果，然后清空join_buffer ，再放入 t2 表剩余200行记录，再次从 t1 表里取数据跟 join_buffer 中数据对比。所以就多扫了一次 t1 表。

被驱动表的关联字段没索引为什么要选择使用 BNL 算法而不使用 Nested-Loop Join 呢？
如果上面第二条sql使用 Nested-Loop Join，那么扫描行数为 100 * 10000 = 100万次，这个是磁盘扫描。
很显然，用BNL磁盘扫描次数少很多，相比于磁盘扫描，BNL的内存计算会快得多。
因此MySQL对于被驱动表的关联字段没索引的关联查询，一般都会使用 BNL 算法。如果有索引一般选择 NLJ 算法，有索引的情况下 NLJ 算法比 BNL算法性能更高

2.3、对于关联sql的优化

关联字段加索引，让mysql做join操作时尽量选择NLJ算法，驱动表因为需要全部查询出来，所以过滤的条件也尽量要走索引，避免全表扫描，总之，能走索引的过滤条件尽量都走索引
小表驱动大表，写多表连接sql时一定要注意使用小表驱动大表

**对于小表定义的明确 **
在决定哪个表做驱动表的时候，应该是两个表按照各自的条件过滤，过滤完成之后，计算参与 join 的各个字段的总数据量，数据量小的那个表，就是“小表”，应该作为驱动表。

3、count(*)查询优化

3.1 4种统计行数对比

结论：count(*) 效率最高

EXPLAIN select count(1) from employees1;
EXPLAIN select count(id) from employees1;
EXPLAIN select count(name) from employees1;
EXPLAIN select count(*) from employees1;

select count(1) from employees1;
select count(id) from employees1;
select count(name) from employees1;
select count(*) from employees1;

**注意：以上4条sql只有根据某个字段count不会统计字段为null值的数据行（**count(id)和count(name)）
四个sql的执行计划一样，说明这四个sql执行效率应该差不多。

字段有索引：count()≈count(1)>count(字段)>count(主键 id) //字段有索引，count(字段)统计走二级索引，二级索引存储数据比主键索引少，所以count(字段)>count(主键 id) **
**字段无索引：count()≈count(1)>count(主键 id)>count(字段) //字段没有索引count(字段)统计走不了索引，count(主键 id)还可以走主键索引，所以count(主键 id)>count(字段)

count(1)跟count(字段)执行过程类似，不过count(1)不需要取出字段统计，就用常量1做统计，count(字段)还需要取出字段，所以理论上count(1)比count(字段)会快一点。

count(**) 是例外，mysql并不会把全部字段取出来，而是专门做了优化，不取值，按行累加，效率很高，所以不需要用count(列名)或count(常量)来替代 count(*)。

为什么对于count(id)，mysql最终选择辅助索引而不是主键聚集索引？因为二级索引相对主键索引存储数据更少，检索性能应该更高，mysql内部做了点优化(应该是在5.7版本才优化)。

3.2 count(*)常见优化方法

1、show table status
如果只需要知道表总行数的估计值可以用如下sql查询，性能很高

2、将总数维护到Redis里
插入或删除表数据行的时候同时维护redis里的表总行数key的计数值(用incr或decr命令)，但是这种方式可能不准，很难保证表操作和redis操作的事务一致性
3、增加数据库计数表
插入或删除表数据行的时候同时维护计数表，让他们在同一个事务里操作

4、sql优化14个技巧（重要）

bfe55c106fb1ceb9316542c424cecf9f_32ea90df4a63669812ba191e6c68d560.png

1 避免使用select *

很多时候，我们写sql语句时，为了方便，喜欢直接使用select *，一次性查出表中所有列的数据。
反例：

#联合索引第一个字段用范围一般不会走索引
EXPLAIN SELECT * FROM employees1 WHERE name > 'A' AND age = 22 AND position ='manager';

在实际业务场景中，可能我们真正需要使用的只有其中一两列。查了很多数据，但是不用，白白浪费了数据库资源。
还回导致很严重的问题是：select *不会走覆盖索引，而从导致查询sql的性能很低。
正例：

#覆盖索引优化
EXPLAIN SELECT  name,age,position FROM employees1 WHERE name > 'Z' AND age = 22 AND position ='manager';

sql语句查询时，只查需要用到的列，多余的列根本无需查出来。

2 用union all代替union

我们都知道sql语句使用union关键字后，可以获取排重后的数据。
而如果使用union all关键字，可以获取所有数据，包含重复的数据。
反例：

(select * from user where id=1) 
union 
(select * from user where id=2);

排重的过程需要遍历、排序和比较，它更耗时，更消耗cpu资源。
所以如果能用union all的时候，尽量不用union。
正例：

(select * from user where id=1) 
union all
(select * from user where id=2);

除非是有些特殊的场景，比如union all之后，结果集中出现了重复数据，而业务场景中是不允许产生重复数据的，这时可以使用union。

3 小表驱动大表

略

4 批量操作

如果你有一批数据经过业务处理之后，需要插入数据，该怎么办？
反例：

for(Order order: list){
    orderMapper.insert(order):
}

在循环中逐条插入数据。

INSERT INTO `order`(`id`, `code`, `user_id`) VALUES (1,'001',100);

该操作需要多次请求数据库，才能完成这批数据的插入。
但众所周知，我们在代码中，每次远程请求数据库，是会消耗一定性能的。而如果我们的代码需要请求多次数据库，才能完成本次业务功能，势必会消耗更多的性能。
那么如何优化呢？
正例：
orderMapper.insertBatch(list):
提供一个批量插入数据的方法。

INSERT INTO `order`(`id`, `code`, `user_id`) VALUES (2,'002',200),(3,'003',300),(4,'004',400);

这样只需要远程请求一次数据库，sql性能会得到提升，数据量越多，提升越大。
但需要注意的是，不建议一次批量操作太多的数据，如果数据太多数据库响应也会很慢。批量操作需要把握一个度，建议每批数据尽量控制在500以内。如果数据多于500，则分多批次处理。

5 多用limit

有时候，我们需要查询某些数据中的第一条，比如：查询某个用户下的第一个订单，想看看他第一次的首单时间。
反例：

select id, create_date 
from `order` 
where user_id=123 
order by create_date asc;

根据用户id查询订单，按下单时间排序，先查出该用户所有的订单数据，得到一个订单集合。然后在代码中，获取第一个元素的数据，即首单的数据，就能获取首单时间。

List<Order> list = orderMapper.getOrderList();
Order order = list.get(0);

虽说这种做法在功能上没有问题，但它的效率非常不高，需要先查询出所有的数据，有点浪费资源。
那么，如何优化呢？
正例：

select id, create_date 
from `order` 
where user_id=123 
order by create_date asc 
limit 1;

使用limit 1，只返回该用户下单时间最小的那一条数据即可。

6 in中值太多

对于批量查询接口，我们通常会使用in关键字过滤出数据。比如：想通过指定的一些id，批量查询出用户信息。
sql语句如下：

select id,name from category
where id in (1,2,3...100000000);

如果我们不做任何限制，该查询语句一次性可能会查询出非常多的数据，很容易导致接口超时。
这时该怎么办呢？

select id,name from category
where id in (1,2,3...100)
limit 500;

可以在sql中对数据用limit做限制。
不过我们更多的是要在业务代码中加限制，伪代码如下：

public List<Category> getCategory(List<Long> ids) {
    if(CollectionUtils.isEmpty(ids)) {
        return null;
    }
    if(ids.size() > 500) {
        throw new BusinessException("一次最多允许查询500条记录")
            }
    return mapper.getCategoryList(ids);
}

还有一个方案就是：如果ids超过500条记录，可以分批用多线程去查询数据。每批只查500条记录，最后把查询到的数据汇总到一起返回。
不过这只是一个临时方案，不适合于ids实在太多的场景。因为ids太多，即使能快速查出数据，但如果返回的数据量太大了，网络传输也是非常消耗性能的，接口性能始终好不到哪里去。

7 高效的分页

有时候，列表页在查询数据时，为了避免一次性返回过多的数据影响接口性能，我们一般会对查询接口做分页处理。
在mysql中分页一般用的limit关键字：

select id,name,age 
from `user` limit 10,20;

如果表中数据量少，用limit关键字做分页，没啥问题。但如果表中数据量很多，用它就会出现性能问题。
比如现在分页参数变成了：

select id,name,age 
from `user` limit 1000000,20;

mysql会查到1000020条数据，然后丢弃前面的1000000条，只查后面的20条数据，这个是非常浪费资源的。
那么，这种海量数据该怎么分页呢？
优化sql：

select id,name,age 
from `user` where id > 1000000 limit 20;

先找到上次分页最大的id，然后利用id上的索引查询。不过该方案，要求id是连续的，并且有序的。

8 用连接查询代替子查询

mysql中如果需要从两张以上的表中查询出数据的话，一般有两种实现方式：子查询和连接查询。
子查询的例子如下：

select * from `order`
where user_id in (select id from user where status=1)

子查询语句可以通过in关键字实现，一个查询语句的条件落在另一个select语句的查询结果中。程序先运行在嵌套在最内层的语句，再运行外层的语句。
子查询语句的优点是简单，结构化，如果涉及的表数量不多的话。
但缺点是mysql执行子查询时，需要创建临时表，查询完毕后，需要再删除这些临时表，有一些额外的性能消耗。
这时可以改成连接查询。具体例子如下：

SELECT
	o.* 
FROM
	`order` o
	INNER JOIN `user` u ON o.user_id = u.id 
WHERE
	u.STATUS =1

9 join的表不宜过多

根据阿里巴巴开发者手册的规定，join表的数量不应该超过3个。
反例：

select a.name,b.name.c.name,d.name
from a 
inner join b on a.id = b.a_id
inner join c on c.b_id = b.id
inner join d on d.c_id = c.id
inner join e on e.d_id = d.id
inner join f on f.e_id = e.id
inner join g on g.f_id = f.id

如果join太多，mysql在选择索引的时候会非常复杂，很容易选错索引。
并且如果没有命中中，nested loop join 就是分别从两个表读一行数据进行两两对比，复杂度是 n^2。
所以我们应该尽量控制join表的数量。
正例：

select a.name,b.name.c.name,a.d_name 
from a 
inner join b on a.id = b.a_id
inner join c on c.b_id = b.id

如果实现业务场景中需要查询出另外几张表中的数据，可以在a、b、c表中冗余专门的字段，比如：在表a中冗余d_name字段，保存需要查询出的数据。
不过我之前也见过有些ERP系统，并发量不大，但业务比较复杂，需要join十几张表才能查询出数据。
所以join表的数量要根据系统的实际情况决定，不能一概而论，尽量越少越好。

10 join时要注意

我们在涉及到多张表联合查询的时候，一般会使用join关键字。
而join使用最多的是left join和inner join。

left join：求两个表的交集外加左表剩下的数据。
inner join：求两个表交集的数据。

使用inner join的示例如下：

select o.id,o.code,u.name 
from order o 
inner join user u on o.user_id = u.id
where u.status=1;

如果两张表使用inner join关联，mysql会自动选择两张表中的小表，去驱动大表，所以性能上不会有太大的问题。
使用left join的示例如下：

select o.id,o.code,u.name 
from order o 
left join user u on o.user_id = u.id
where u.status=1;

如果两张表使用left join关联，mysql会默认用left join关键字左边的表，去驱动它右边的表。如果左边的表数据很多时，就会出现性能问题。
要特别注意的是在用left join关联查询时，左边要用小表，右边可以用大表。如果能用inner join的地方，尽量少用left join。

11 控制索引的数量

众所周知，索引能够显著的提升查询sql的性能，但索引数量并非越多越好。
因为表中新增数据时，需要同时为它创建索引，而索引是需要额外的存储空间的，而且还会有一定的性能消耗。
阿里巴巴的开发者手册中规定，单表的索引数量应该尽量控制在5个以内，并且单个索引中的字段数不超过5个。
mysql使用的B+树的结构来保存索引的，在insert、update和delete操作时，需要更新B+树索引。如果索引过多，会消耗很多额外的性能。
那么，问题来了，如果表中的索引太多，超过了5个该怎么办？
这个问题要辩证的看，如果你的系统并发量不高，表中的数据量也不多，其实超过5个也可以，只要不要超过太多就行。
但对于一些高并发的系统，请务必遵守单表索引数量不要超过5的限制。
那么，高并发系统如何优化索引数量？
能够建联合索引，就别建单个索引，可以删除无用的单个索引。

12 选择合理的字段类型

char表示固定字符串类型，该类型的字段存储空间的固定的，会浪费存储空间。

alter table order 
add column code char(20) NOT NULL;

varchar表示变长字符串类型，该类型的字段存储空间会根据实际数据的长度调整，不会浪费存储空间。

alter table order 
add column code varchar(20) NOT NULL;

如果是长度固定的字段，比如用户手机号，一般都是11位的，可以定义成char类型，长度是11字节。
但如果是企业名称字段，假如定义成char类型，就有问题了。
如果长度定义得太长，比如定义成了200字节，而实际企业长度只有50字节，则会浪费150字节的存储空间。
如果长度定义得太短，比如定义成了50字节，但实际企业名称有100字节，就会存储不下，而抛出异常。
所以建议将企业名称改成varchar类型，变长字段存储空间小，可以节省存储空间，而且对于查询来说，在一个相对较小的字段内搜索效率显然要高些。
我们在选择字段类型时，应该遵循这样的原则：

能用数字类型，就不用字符串，因为字符的处理往往比数字要慢。
尽可能使用小的类型，比如：用bit存布尔值，用tinyint存枚举值等。
长度固定的字符串字段，用char类型。
长度可变的字符串字段，用varchar类型。
金额字段用decimal，避免精度丢失问题。

13 提升group by的效率

我们有很多业务场景需要使用group by关键字，它主要的功能是去重和分组。
通常它会跟having一起配合使用，表示分组后再根据一定的条件过滤数据。
反例：

select user_id,user_name from order
group by user_id
having user_id <= 200;

这种写法性能不好，它先把所有的订单根据用户id分组之后，再去过滤用户id大于等于200的用户。
分组是一个相对耗时的操作，为什么我们不先缩小数据的范围之后，再分组呢？
正例：

select user_id,user_name from order
where user_id <= 200
group by user_id

使用where条件在分组前，就把多余的数据过滤掉了，这样分组时效率就会更高一些。
其实这是一种思路，不仅限于group by的优化。我们的sql语句在做一些耗时的操作之前，应尽可能缩小数据范围，这样能提升sql整体的性能。

14 索引优化

sql优化当中，有一个非常重要的内容就是：索引优化。
很多时候sql语句，走了索引，和没有走索引，执行效率差别很大。所以索引优化被作为sql优化的首选。
索引优化的第一步是：检查sql语句有没有走索引。
那么，如何查看sql走了索引没？
可以使用explain命令，查看mysql的执行计划。
例如：

explain select * from `order` where code='002';

通过判断索引使用情况，执行计划包含列的含义如下图所示：
2cdad3a89f9a4bff968255282d008321_af363bb474a8894c6ca33ffd3a37c9d0.png

5、索引失效的10种场景

9a357cb9099f5f4989304e300eca2dc6_574c967e8ca796768e2287b006bc0109.png

准备工作

创建user表

创建一张user表，表中包含：id、code、age、name和height、address字段。

CREATE TABLE `user` (
  `id` int NOT NULL AUTO_INCREMENT,
  `code` varchar(20) DEFAULT NULL,
  `age` int DEFAULT '0',
  `name` varchar(30) DEFAULT NULL,
  `height` int DEFAULT '0',
  `address` varchar(30)  DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `idx_code_age_name` (`code`,`age`,`name`),
  KEY `idx_height` (`height`)
) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8;

此外，还创建了三个索引：

id：数据库的主键
idx_code_age_name：由code、age和name三个字段组成的联合索引。
idx_height：普通索引

插入数据

为了方便给大家做演示，我特意向user表中插入了3条数据：

INSERT INTO user (id, code, age, name, height,address) VALUES (1, '101', 21, '张三', 175,'北京');
INSERT INTO user (id, code, age, name, height,address) VALUES (2, '102', 18, '李四', 173,'上海');
INSERT INTO user (id, code, age, name, height,address) VALUES (3, '103', 23, '王二', 174,'成都');

查看数据库版本

select version();

查出当前的mysql版本号为：8.0.27

1. 不满足最左匹配原则

之前我已经给code、age和name这3个字段建好联合索引：idx_code_age_name。
该索引字段的顺序是：

code
age
name

如果在使用联合索引时，没注意最左前缀原则，很有可能导致索引失效。

1.1 索引有效

正例

explain select * from user
where code='101';

explain select * from user
where code='101' and age=21

explain select * from user
where code='101' and age=21 and name='张三';

上面三种情况，sql都能正常走索引。
其实还有一种比较特殊的场景：

explain select * from user
where code = '101'  and name='张三';

查询条件原本的顺序是：code、age、name，但这里只有code和name中间断层了，掉了age字段，这种情况也能走code字段上的索引。
这4条sql中都有code字段，它是索引字段中的第一个字段，也就是最左边的字段。只要有这个字段在，该sql已经就能走索引。
这就是我们所说的最左匹配原则。

1.2 索引失效

前面我已经介绍过，建立了联合索引后，在查询条件中有哪些情况索引是有效的。
接下来，我们重点看看哪些情况下索引会失效。

explain select * from user
where age=21;

explain select * from user
where name='xx';

explain select * from user
where age=21 and name='xx';

说明以上3种情况不满足最左匹配原则，说白了是因为查询条件中，没有包含给定字段最左边的索引字段，即字段code

2. 使用了select *

在《阿里巴巴开发手册》中明确说过，查询sql中禁止使用select * 。
譬如：

explain 
select * from user where name='xx';

在该sql中用了select *，从执行结果看，走了全表扫描，没有用到任何索引，查询效率是非常低的。
结论：查询的时候，只查我们真正需要的列，而不查所有列

explain 
select code,name from user 
where name='xx';

该sql语句这次走了全索引扫描，比全表扫描效率更高。
其实这里用到了：覆盖索引。
如果select语句中的查询列，都是索引列，那么这些列被称为覆盖索引。这种情况下，查询的相关字段都能走索引，索引查询效率相对来说更高一些。
而使用select *查询所有列的数据，大概率会查询非索引列的数据，非索引列不会走索引，查询效率非常低。

3. 索引列上有计算

explain select * from user where id+1=2;

4、索引列用了函数

Mysql函数大全及举例
http://www.shouxieziti.cn/279.html

explain select * from user  where SUBSTR(height,1,2)=17;

5. 字段类型不同

正例：

explain 
select * from user where code='101';

反例：
code字段的类型是varchar，而传参的类型是int，两种类型不同。

explain 
select * from user where code=101;

特例：
如果int类型的height字段，在查询时加了引号条件，却还可以走索引：

explain select * from user 
where height='175';

mysql发现如果是int类型字段作为查询条件时，它会自动将该字段的传参进行隐式转换，把字符串转换成int类型。
mysql会把上面列子中的字符串175，转换成数字175，所以仍然能走索引。

6. like左边包含%

explain select * from user
where code like '%1%';

7. 使用or关键字

我们平时在写查询sql时，使用or关键字的场景非常多，但如果你稍不注意，就可能让已有的索引失效。

#生效
explain select * from user 
where id=1 or height='175';

#失效
explain select * from user 
where id=1 or height='175' or name = '张三';

总结：查询条件中带有or,除非所有的查询条件都建有索引，否则索引失效

8. not in

在我们日常工作中用得也比较多的，还有范围查询，常见的有：

in
not in

8.1 in关键字

假如我们想查出height在某些范围之内的用户，这时sql语句可以这样写：
sql语句中用in关键字是走了索引的

explain select * from user
where height in (173,174,175,176);

8.2 not in关键字

先看看使用not in的情况：
索引失效：

explain select * from user
where height not in (173,174,175,176);

看如果现在需求改了：想查一下id不等于1、2、3的用户有哪些，这时sql语句可以改成这样：
主键字段中使用not in可以走索引

explain select * from user
where id  not in (173,174,175,176);

结论：

主键字段中使用not in关键字查询数据范围，可以走索引。
而普通索引字段使用了not in关键字查询数据范围，索引会失效。

9. order by的坑

略