SQL 优化方案(规范)

1、SQL执行顺序

• SELECT DISTINCT column,… (选择字段 、去重)
• AGG_FUNC(column or expression),… (聚合函数)
• FROM [left_table] (选择表)
• JOIN (连接)
• ON (连接条件)
• WHERE (条件过滤)
• GROUP BY (分组)
• HAVING (分组过滤)
• ORDER BY (排序)
• LIMIT count OFFSET count; (分页)

2、前置条件

2.1、使用explain分析SQL执行计划

SQL很灵活，一个需求可以很多实现，那哪个最优呢？SQL提供了explain关键字，它可以分析你的SQL执行计划，看它是否最佳。Explain主要看SQL是否使用了索引。

EXPLAIN
SELECT * FROM student WHERE id=1

返回结果：

不清楚EXPLAIN解析器的同学可以先去看看这篇文章: SQL EXPLAIN解析器

2.2、开启慢sql日志

默认情况下slow_query_log的值为OFF，表示慢查询日志是禁用的，可以通过设置slow_query_log的值来开启，如下所示：

1、查询慢日志是否开启

show variables like ‘%slow_query_log%’;

2、开启慢查询日志(OFF 为关闭 ON为开启)

set global slow_query_log=ON;

注意：使用set global
slowquerylog=1开启了慢查询日志只对当前数据库生效，MySQL重启后失效。如果要永久生效，就必须修改配置文件my.cnf

3、永久开启慢查询日志

修改my.cnf文件，增加或修改参数slow_query_log 和slow_query_log_file后，然后重启MySQL服务器，
    slow_query_log =1
    slow_query_log_file=/usr/local/mysql/data/localhost-slow.log

4、设置日志路径和未使用索引的查询(有默认值，可以不设置)

log-slow-queries = /usr/local/mysql/data/slow.log #定义慢查询日志路径。
log-queries-not-using-indexes #未使用索引的查询也被记录到慢查询日志中（可选）。

2.3、慢查询时间设置。默认情况下long_query_time的值为10秒，可以使用命令修改，也可以在my.cnf参数里面修改。

1、查询慢日志时间

show variables like ‘long_query_time’;

注：如果设置了日志时间，对当前会话是无效的。所以用全局查询 show global variables like ‘long_query_time’;

2、设置慢查询日志时间

set global long_query_time=3;

3、查看总执行了多少次慢sql

show global status like '%slow%';  

3、基础Sql优化

3.1、小表驱动大表

• in 的话里面驱动外面，in适合里子查询是小表
• exist 的话外面驱动里面，适合外面是小表

3.2、高效的分页

反例：

select id,name,age from user limit 10000, 20;

mysql会查询10020条，然后丢弃前面10000条，这个比较浪费资源

正例：

-- 可以取前一页的最大行数的id，然后根据这个最大的id来限制下一页的起点
select id,name,age from user id>10000 limit 20;

找到上次分页最大id, 假如id是连续的，并且有序，可以用between

注意： between要在唯一索引上分页，不然会出现每页大小不一致问题。

3.3、分段查询

在一些用户选择页面中，可能一些用户选择的时间范围过大，造成查询缓慢。主要的原因是扫描行数过多。这个时候可以通过程序，分段进行查询，循环遍历，将结果合并处理进行展示。

如下图这个SQL语句，扫描的行数成百万级以上的时候就可以使用分段查询：

3.4、注意范围查询语句

注: < > >= <= 都有可能不走索引, 索引失效是因为DBMS发现全表扫描比走索引效率更高，因此就放弃了走索引, 当Mysql发现通过索引扫描的行记录数超过全表的10%-30%时，优化器可能会放弃走索引，自动变成全表扫描。

解决方式: 参照 3.16.3、force index(索引): 强制使用该索引

3.5、查询SQL尽量不要使用select *，而是具体字段

反例：

SELECT * FROM student

正例：

SELECT id,NAME FROM student

理由：

• SELECT*增加很多不必要的消耗（CPU、IO、内存、网络带宽）
• 字段多时，大表能达到100多个字段甚至达200多个字段
• 只取需要的字段，节省资源、减少网络开销
• select * 进行查询时，很可能不会用到索引，就会造成全表扫描
• 增加了使用覆盖索引的可能性；当表结构发生改变时，前断也需要更新。所以要求直接在select后面接上字段名

3.6、当只需要一条数据的时候，使用limit 1

为了使EXPLAIN中type列达到const类型，如果加上limit1，查找到就不用继续往后找了

3.7、如果排序字段没有用到索引，就尽量少排序

可以在程序中排序

3.8、如果限制条件中其他字段没有索引，尽量少用or

or两边的字段中，如果有一个不是索引字段，而其他条件也不是索引字段，会造成该查询不走索引的情况。很多时候使用union all或者是union（必要的时候）的方式来代替“or”会得到更好的效果。

3.9、避免在where子句中使用or来连接条件

查询id为1或者薪水为3000的用户
反例：

SELECT * FROM student WHERE id=1 OR salary=30000

正例：使用union all

SELECT * FROM student WHERE id=1
UNION ALL
SELECT * FROM student WHERE salary=30000

分开两条sql写

SELECT * FROM student WHERE id=1
SELECT * FROM student WHERE salary=30000

理由：

• 使用or可能会使索引失效，从而全表扫描
• 对于or没有索引的salary这种情况，假设它走了id的索引，但是走到salary查询条件时，它还得全表扫描。也就是说整个过程需要三步：全表扫描+索引扫描+合并。如果它一开始就走全表扫描，直接一遍扫描就搞定。虽然mysql是有优化器的，处于效率与成本考虑，遇到or条件，索引还是可能失效的

3.10、字符串类型必须带’'引号

字符串类型的字段, 查询的时候如果不加引号’’ ,会导致自动进行隐式转换,然后索引失效

3.11、使用varchar代替char

反例：

`deptname` char(100) DEFAULT NULL COMMENT '部门名称'

正例：

`deptname` varchar(100) DEFAULT NULL COMMENT '部门名称'

理由：

• varchar变长字段按数据内容实际长度存储，存储空间小，可以节省存储空间
• char按声明大小存储，不足补空格
• 对于查询来说，在一个相对较小的字段内搜索，效率更高

3.12、选择合理的字段类型

• 能用数字类型就不用字符串，字符串处理速度比数字类型慢
• 尽量用小类型，比如：用bit存布尔值，用tinyint存枚举值等。
• 长度固定字符串用char，不固定用varchar

3.13、尽量使用数值替代字符串类型

• 主键（id）：primary key优先使用数值类型int，tinyint
• 性别（sex）：0-代表女，1-代表男；数据库没有布尔类型，mysql推荐使用tinyint
• 支付方式（payment）：1-现金、2-微信、3-支付宝、4-信用卡、5-银行卡
• 服务状态（state）：1-开启、2-暂停、3-停止
• 商品状态（state）：1-上架、2-下架、3-删除

3.14、查询尽量避免返回大量数据

如果查询返回数据量很大，就会造成查询时间过长，网络传输时间过长。同时，大量数据返回也可能没有实际意义。如返回上千条甚至更多，用户也看不过来。
通常采用分页，一页习惯10/20/50/100条。

3.15、正确的建立索引

索引的建立对sql的影响是非常大的,如果对索引不太理解的先看下这篇文章: MySQL进阶:索引的使用及理解

select  * from user_test  WHERE uid=15988;
select  * from user_test  WHERE address=15988;  可以看到有索引的查找速度非常快.

3.16、指定查询的索引[建议]

当sql查询的字段有多个索引的时候,mysql优化器会自动选择一个索引进行查询,我们也可以通过sql字段进行自定义

3.16.1、use index(索引): 推荐使用指定的索引 (最终用不用该索引,还需要mysql自己判断)

select * from  use index(索引A)  

3.16.2、ignore index(索引) : 忽略掉这个索引

select * from  ignore index(索引A) 

3.16.3、force index(索引): 强制使用该索引

-- 有时候MySQL优化器采取它认为合适的索引来检索SQL语句，但是可能它所采用的索引并不是我们想要的。这时就可以采用forceindex来强制优化器使用指定的索引。
select * from  force index(索引A)

3.17、是否使用了索引及其扫描类型

SQL索引概念（详解B+树）
type：

• ALL 全表扫描，没有优化，最慢的方式
• index 索引全扫描
• range 索引范围扫描，常用语<，<=，>=，between等操作
• ref 使用非唯一索引扫描或唯一索引前缀扫描，返回单条记录，常出现在关联查询中
• eq_ref 类似ref，区别在于使用的是唯一索引，使用主键的关联查询
• const 当查询是对主键或者唯一键进行精确查询，系统会把匹配行中的其他列作为常数处理
• null MySQL不访问任何表或索引，直接返回结果
• System 表只有一条记录(实际中基本不存在这个情况)

性能排行：
System > const > eq_ref > ref > range > index > ALL

possible_keys：显示可能应用在这张表中的索引
key：真正使用的索引方式

3.18、优化like语句

模糊查询，程序员最喜欢的就是使用like，但是like很可能会导致索引失效
反例：

EXPLAIN
SELECT id,NAME FROM student WHERE NAME LIKE '%1'
EXPLAIN
SELECT id,NAME FROM student WHERE NAME LIKE '%1%'

正例：

EXPLAIN
SELECT id,NAME FROM student WHERE NAME LIKE '1%'

理由：
未使用索引：故意使用sex非索引字段

EXPLAIN
SELECT id,NAME FROM student WHERE NAME=1 OR sex=1

主键索引生效

EXPLAIN
SELECT id,NAME FROM student WHERE id=1

索引失效，type=ALL，全表扫描

EXPLAIN
SELECT id,NAME FROM student WHERE id LIKE '%1'

3.19、避免隐式类型转换

反例：

#未使用索引
EXPLAIN
SELECT * FROM student WHERE NAME=123

正例：

#使用索引
EXPLAIN
SELECT * FROM student WHERE NAME='123'

理由：

• 为什么第一条语句未加单引号就不走索引了呢？这是因为不加单引号时，是字符串跟数字的比较，它们类型不匹配，MySQL会做隐式的类型转换，把它们转换为数值类型再做比较
• where子句中出现column字段的类型和传入的参数类型不一致的时候发生的类型转换，建议先确定where中的参数类型。

3.20、索引不宜太多，一般5个以内

• 索引并不是越多越好，虽其提高了查询的效率，但却会降低插入和更新的效率
• 索引可以理解为一个就是一张表，其可以存储数据，其数据就要占空间
• 索引表的一个特点，其数据是排序的，那排序要不要花时间呢？肯定要insert或update时有可能会重建索引，如果数据量巨大，重建将进行记录的重新排序，所以建索引需要慎重考虑，视具体情况来定
• 一个表的索引数最好不要超过5个，若太多需要考虑一些索引是否有存在的必要

3.21、索引不适合建在有大量重复数据的字段上

如性别字段。因为SQL优化器是根据表中数据量来进行查询优化的，如果索引列有大量重复数据，Mysql查询优化器推算发现不走索引的成本更低，很可能就放弃索引了。

3.22、where限定查询的数据

数据中假定就一个男的记录
反例：

SELECT id,NAME FROM student WHERE sex='男'

正例：

SELECT id,NAME FROM student WHERE id=1 AND sex='男'

理由：

• 需要什么数据，就去查什么数据，避免返回不必要的数据，节省开销

3.23、避免在索引列上使用内置函数

业务需求：查询最近七天内新生儿（用学生表替代下）
给birthday字段创建索引：

ALTER TABLE student ADD INDEX idx_birthday (birthday)

当前时间加7天：

SELECT NOW()	
SELECT DATE_ADD(NOW(), INTERVAL 7 DAY)

反例：

EXPLAIN
SELECT * FROM student
WHERE DATE_ADD(birthday,INTERVAL 7 DAY) >=NOW();

正例：

EXPLAIN
SELECT * FROM student
WHERE  birthday >= DATE_ADD(NOW(),INTERVAL 7 DAY);

理由：

• 使用索引列上内置函数
• 索引失效
  
  索引有效：
  

3.24、避免在where中对字段进行表达式操作

反例：

EXPLAIN
SELECT * FROM student WHERE id+1-1=+1

正例：

EXPLAIN
SELECT * FROM student WHERE id=+1-1+1

EXPLAIN
SELECT * FROM student WHERE id=1

理由：
SQL解析时，如果字段相关的是表达式就进行全表扫描

字段干净无表达式，索引生效

3.25、避免在where子句中使用!=或<>操作符

应尽量避免在where子句中使用!=或<>操作符，否则引擎将放弃使用索引而进行全表扫描。记住实现业务优先，实在没办法，就只能使用，并不是不能使用。如果不能使用，SQL也就无需支持了。

反例：

EXPLAIN
SELECT * FROM student WHERE salary!=3000

EXPLAIN
SELECT * FROM student WHERE salary<>3000

理由：

• 使用!=和<>很可能会让索引失效
  

3.26、去重distinct过滤字段要少

#索引失效
EXPLAIN
SELECT DISTINCT * FROM student

#索引生效
EXPLAIN
SELECT DISTINCT id,NAME FROM student

EXPLAIN
SELECT DISTINCT NAME FROM student

理由：

• 带distinct的语句占用cpu时间高于不带distinct的语句。因为当查询很多字段时，如果使用distinct，数据库引擎就会对数据进行比较，过滤掉重复数据，然而这个比较、过滤的过程会占用系统资源，如cpu时间

3.27、where中使用默认值代替null

环境准备：

#修改表，增加age字段，类型int，非空，默认值0
ALTER TABLE student ADD age INT NOT NULL DEFAULT 0;

#修改表，增加age字段的索引，名称为idx_age
ALTER TABLE student ADD INDEX idx_age (age);

反例：

EXPLAIN
SELECT * FROM student WHERE age IS NOT NULL

正例：

EXPLAIN
SELECT * FROM student WHERE age>0

理由：

• 并不是说使用了is null 或者 is not null 就会不走索引了，这个跟mysql版本以及查询成本都有关
• 如果mysql优化器发现，走索引比不走索引成本还要高，就会放弃索引，这些条件 !=，<>，is null，is not null经常被认为让索引失效，其实是因为一般情况下，查询的成本高，优化器自动放弃索引的
• 如果把null值，换成默认值，很多时候让走索引成为可能，同时，表达意思也相对清晰一点

4、高级SQL优化

4.1、创建表时使用同一的编码

mysql多表联查时,如果表的字符集不一样,会有一个数据类型转换的过程

例如: utf8 与utf8mb4前者是3字节unicode编码，后者是4字节unicode编码. 此时如果多表查询,则索引会失效

4.2、insert插入优化

• 需要插入多条数据的时候 使用批量插入.(多次插入需要频繁的建立连接.浪费资源)
• 多次插入数据时,采用手动提交事务
  • sql语句在执行的时候如下所示, 会自动开启事务和提交事务. 我们可以手动开启事务,然后执行多条sql后,在手动提交事务.减少资源浪费

start transaction;   执行sql;   commit;

4.3、批量插入性能提升

大量数据提交，上千，上万，批量性能非常快，mysql独有
多条提交：

INSERT INTO student (id,NAME) VALUES(4,'name1');
INSERT INTO student (id,NAME) VALUES(5,'name2');

批量提交：

INSERT INTO student (id,NAME) VALUES(4,'name1'),(5,'name2');

理由：

• 默认新增SQL有事务控制，导致每条都需要事务开启和事务提交；而批量处理是一次事务开启和提交。自然速度飞升
• 数据量小体现不出来

4.4、update优化 (避免出现表锁)

innodb引擎使用update时,会有行锁/表锁两种模式, 如果where 字段没有索引的时候会升级成表锁

update table set xx=1 where  name=xx   (name没有索引,此时是表锁)
update table set xx=1 where  id=xx  (id有索引,此时是行锁)

4.5、批量删除优化

避免同时修改或删除过多数据，因为会造成cpu利用率过高，会造成锁表操作，从而影响别人对数据库的访问。

反例：

#一次删除10万或者100万+？
delete from student where id <100000;

#采用单一循环操作，效率低，时间漫长
for（User user:list）{
  delete from student;
}

正例：

#分批进行删除，如每次500
for(){
delete student where id<500;
}

delete student where id>=500 and id<1000;

理由：

• 一次性删除太多数据，可能造成锁表，会有lock wait timeout exceed的错误，所以建议分批操作

4.6、伪删除设计

商品状态（state）：1-上架、2-下架、3-删除

理由：

• 这里的删除只是一个标识，并没有从数据库表中真正删除，可以作为历史记录备查
• 同时，一个大型系统中，表关系是非常复杂的，如电商系统中，商品作废了，但如果直接删除商品，其它商品详情，物流信息中可能都有其引用。
• 通过where state=1或者where state=2过滤掉数据，这样伪删除的数据用户就看不到了，从而不影响用户的使用
• 操作速度快，特别数据量很大情况下

4.7、order by 排序优化 (排序时,使用有索引的字段进行排序)

使用order by排序时,会出现两种情况 (explain查看Extra字段)

• using fileSort : 全表扫描,读取出数据,然后再排序缓冲区进行排序. (排序字段没有索引)
• using index: 通过索引直接返回有序的数据. 不需要额外排序(有索引,效率高)

4.8、不使用ORDER BY RAND()

想打乱返回的数据行?随机挑一个数据?真不知道谁发明了这种用法，但很多新手很喜欢这样用。但你确不了解这样做有多么可怕的性能问题。

如果你真的想把返回的数据行打乱了，你有N种方法可以达到这个目的。这样使用只让你的数据库的性能呈指数级的下降。这里的问题是：MySQL会不得不去执行RAND()函数(很耗CPU时间)，而且这是为了每一行记录去记行，然后再对其排序。就算是你用了Limit 1也无济于事(因为要排序)。

select id from `dynamic` order by rand() limit 1000;

上面的SQL语句，可优化为：

select id from `dynamic` t1 join (select rand() * (select max(id) from `dynamic`) as nid) t2 on t1.id > t2.nidlimit 1000;

4.9、count 优化 速度:count(*)>count(1)>count(字段)

inndb引擎的使用如下 (MyIASM默认存了数据总数,所以效率最高)

• count(字段):遍历整张表 会把每一行的字段值取出来,然后返回
• count(1): 便利整张表,但不取值,对于返回的数据,放入1进去.然后累加
• count(*):inndb引擎,特意做了优化,不会取出值,直接服务层进行累加

4.10、提高group by语句的效率

可以在执行到该语句前，把不需要的记录过滤掉
反例：先分组，再过滤

select job，avg（salary） from employee  
group by job 
having job ='president' or job = 'managent';

正例：先过滤，后分组

select job，avg（salary） from employee 
where job ='president' or job = 'managent' 
group by job;

4.11、复合索引最左特性

创建复合索引，也就是多个字段

ALTER TABLE student ADD INDEX idx_name_salary (NAME,salary)

满足复合索引的左侧顺序，哪怕只是部分，复合索引生效

EXPLAIN
SELECT * FROM student WHERE NAME='name1'

没有出现左边的字段，则不满足最左特性，索引失效

EXPLAIN
SELECT * FROM student WHERE salary=3000

复合索引全使用，按左侧顺序出现 name,salary，索引生效

EXPLAIN
SELECT * FROM student WHERE NAME='陈子枢' AND salary=3000

虽然违背了最左特性，但MYSQL执行SQL时会进行优化，底层进行颠倒优化

EXPLAIN
SELECT * FROM student WHERE salary=3000 AND NAME='name1'

理由：

• 复合索引也称为联合索引
• 当我们创建一个联合索引的时候，如(k1,k2,k3)，相当于创建了（k1）、(k1,k2)和(k1,k2,k3)三个索引，这就是最左匹配原则
• 联合索引不满足最左原则，索引一般会失效，但是这个还跟Mysql优化器有关的

4.12、排序字段创建索引

什么样的字段才需要创建索引呢？原则就是where和order by中常出现的字段就创建索引。

#使用*，包含了未索引的字段，导致索引失效
EXPLAIN
SELECT * FROM student ORDER BY NAME;

EXPLAIN
SELECT * FROM student ORDER BY NAME,salary

#name字段有索引
EXPLAIN
SELECT id,NAME FROM student ORDER BY NAME

#name和salary复合索引
EXPLAIN
SELECT id,NAME FROM student ORDER BY NAME,salary

EXPLAIN
SELECT id,NAME FROM student ORDER BY salary,NAME

#排序字段未创建索引，性能就慢
EXPLAIN
SELECT id,NAME FROM student ORDER BY sex

4.13、删除冗余和重复的索引

SHOW INDEX FROM student 

#创建索引index_name
ALTER TABLE student ADD INDEX index_name (NAME)

#删除student表的index_name索引
DROP INDEX index_name ON student ;

#修改表结果，删除student表的index_name索引
ALTER TABLE student DROP INDEX index_name ;

#主键会自动创建索引，删除主键索引
ALTER TABLE student DROP PRIMARY KEY ;

4.14、不要有超过5个以上的表连接

• 关联的表个数越多，编译的时间和开销也就越大
• 每次关联内存中都生成一个临时表
• 应该把连接表拆开成较小的几个执行，可读性更高
• 如果一定需要连接很多表才能得到数据，那么意味着这是个糟糕的设计了
• 阿里规范中，建议多表联查三张表以下

4.15、用连接查询代替子查询[建议]

MySQL如果需要在两张以上表中查询数据的话，一般有两种实现方式

• 子查询
• 连接查询

子查询：

select * from order where user_id in (select id from user where name='zhang'); 

子查询可以通过in实现
优点：简单
缺点：MySQL执行子查询时，需要创建临时表，查询完成后再删除临时表，有一些额外开销。

可以改成连接查询
连接查询：

select o.* from order o inner join user u on o.user_id = u.id where u.name='zhang'; 

4.16、inner join 、left join、right join，优先使用inner join

三种连接如果结果相同，优先使用inner join，如果使用left join左边表尽量小

• inner join 内连接，只保留两张表中完全匹配的结果集
• left join会返回左表所有的行，即使在右表中没有匹配的记录
• right join会返回右表所有的行，即使在左表中没有匹配的记录

理由：

• 如果inner join是等值连接，返回的行数比较少，所以性能相对会好一点
• 同理，使用了左连接，左边表数据结果尽量小，条件尽量放到左边处理，意味着返回的行数可能比较少。这是mysql优化原则，就是小表驱动大表，小的数据集驱动大的数据集，从而让性能更优

4.17、join优化

LEFT JOIN A表为驱动表，INNER JOIN MySQL会自动找出那个数据少的表作用驱动表，RIGHT JOIN B表为驱动表。

注意：

4.17.1、MySQL中没有full join，可以用以下方式来解决

select * from A left join B on B.name = A.namewhere B.name is nullunion allselect * from B;

4.17.2、尽量使用inner join，避免left join

参与联合查询的表至少为2张表，一般都存在大小之分。如果连接方式是inner join，在没有其他过滤条件的情况下MySQL会自动选择小表作为驱动表，但是left join在驱动表的选择上遵循的是左边驱动右边的原则，即left join左边的表名为驱动表。

4.17.3、合理利用索引

被驱动表的索引字段作为on的限制字段。

4.17.4、利用小表去驱动大表

从原理图能够直观的看出如果能够减少驱动表的话，减少嵌套循环中的循环次数，以减少 IO总量及CPU运算的次数。

4.17.5、巧用STRAIGHT_JOIN

inner join是由MySQL选择驱动表，但是有些特殊情况需要选择另个表作为驱动表，比如有group by、order by等「Using filesort」、「Using temporary」时。STRAIGHT_JOIN来强制连接顺序，在STRAIGHT_JOIN左边的表名就是驱动表，右边则是被驱动表。在使用STRAIGHT_JOIN有个前提条件是该查询是内连接，也就是inner join。其他链接不推荐使用STRAIGHT_JOIN，否则可能造成查询结果不准确。

这个方式有时能减少3倍的时间。

4.18、in子查询的优化

日常开发实现业务需求可以有两种方式实现：

• 一种使用数据库SQL脚本实现
• 一种使用程序实现

需求：查询所有部门的所有员工

#in子查询
SELECT * FROM tb_user WHERE dept_id IN (SELECT id FROM tb_dept);
#这样写等价于：

#先查询部门表
SELECT id FROM tb_dept

#再由部门dept_id，查询tb_user的员工
SELECT * FROM tb_user u,tb_dept d WHERE u.dept_id = d.id

假设表A表示某企业的员工表，表B表示部门表，查询所有部门的所有员工，很容易有以下程序实现，可以抽象成这样的一个嵌套循环：

List<> resultSet;
for(int i=0;i<B.length;i++) {
  for(int j=0;j<A.length;j++) {
    if(A[i].id==B[j].id) {
      resultSet.add(A[i]);
      break;
    }
  }
}

上面的需求使用SQL就远不如程序实现，特别当数据量巨大时。
理由：

• 数据库最费劲的就是程序链接的释放。假设链接了两次，每次做上百万次的数据集查询，查完就结束，这样就只做了两次；相反建立了上百万次链接，申请链接释放反复重复，就会额外花费很多实际，这样系统就受不了了，慢，卡顿

4.19、SQL语句中IN包含的值不应过多

MySQL对于IN做了相应的优化，即将IN中的常量全部存储在一个数组里面，而且这个数组是排好序的。但是如果数值较多，产生的消耗也是比较大的。再例如：select id from t where num in(1,2,3) 对于连续的数值，能用between就不要用in了；再或者使用连接来替换。

4.20、尽量使用union all替代union

反例：

SELECT * FROM student
UNION
SELECT * FROM student

正例：

SELECT * FROM student
UNION ALL
SELECT * FROM student

理由：

• union和union all的区别是，union会自动去掉多个结果集合中的重复结果，而union all则将所有的结果全部显示出来，不管是不是重复
• union：对两个结果集进行并集操作，不包括重复行，同时进行默认规则的排序
• union在进行表链接后会筛选掉重复的记录，所以在表链接后会对所产生的结果集进行排序运算，删除重复的记录再返回结果。实际大部分应用中是不会产生重复的记录，最常见的是过程表与历史表UNION

4.21、区分in和exists、not in和not exists

select * from 表A where id in (select id from 表B)

上面SQL语句相当于

select * from 表A where exists(select * from 表B where 表B.id=表A.id)

区分in和exists主要是造成了驱动顺序的改变（这是性能变化的关键），如果是exists，那么以外层表为驱动表，先被访问，如果是IN，那么先执行子查询。所以IN适合于外表大而内表小的情况；EXISTS适合于外表小而内表大的情况。

关于not in和not exists，推荐使用not exists，不仅仅是效率问题，not in可能存在逻辑问题。如何高效的写出一个替代not exists的SQL语句？

原SQL语句：

select colname … from A表 where a.id not in (select b.id from B表)

高效的SQL语句：

select colname … from A表 Left join B表 on where a.id = b.id where b.id is null

取出的结果集如下图表示，A表不在B表中的数据