sql优化的8种方式 （下）

　　五、条件列表值如果连续使用between替代in

       六、无重复记录的结果集使用union all合并

MySQL数据库中使用union或union all运算符将一个或多个列数相同的查询结果集上下合并成为一个查询结果集。其中union会合并各个结果集中相同的记录行，重复记录只显示一次外加自动排序，而union all运算符不去重不排序。因此，对于无重复记录的多个查询结果集应当使用union all合并。参见如下实验：

方法一：select * from t where id=1 union select * from t where id=2;
方法二：select * from t where id=1 union all select * from t where id=2;

使用union运算符由于需要去除重复记录和排序，查询时间为1.229秒高于union all运算符的1.120秒。因此，对于无重复记录的结果集使用union all合并的效率要高。

七、有条件使用where就不使用having

在SELECT查询语句中，where子句和having子句都起到对行记录过滤的作用，主要区别在于having子句是对group by子句产生的结果（可能包含聚合函数），而where子句先于having子句运行，主要目的是缩减查询结果集的行记录数。

方式一：select CountryCode,count() from city where CountryCode=‘CHN’;
方式二：select CountryCode,count() from city group by CountryCode having CountryCode=‘CHN’

使用where子句的方式一的SQL书写方式仅仅耗时1.463秒，远低于耗时6.897秒的使用having子句的SQL书写方式二。其主要原因是方式二的SQL写法是在分组统计了所有国家城市的数量，然后再使用having子句将统计结果过滤出仅仅是中国的城市数量，SQL解析器耗费了大量资源统计了与需求无关的数据，致使查询效率下降。因此，当需求明确时，应尽量使用where子句缩小查询结果集，然后再使用相关聚合函数进行统计分析。

八、使用like操作符时通配符要放在右侧

在书写SQL语句时，如果在where或having子句中使用like模糊匹配操作符，通配符“%”或“_”不要写在匹配字符串的左侧，参见以下两种书写方式：

方式一：select * from t where name like ‘150’;
方式二：select * from t where name like ‘a150_’;

使用like操作符的查询条件列带有索引时，如果通配符放在最左边，索引会失效，SQL优化器会选择效率低的全表扫解析方式，主要原因是对字符串类型创建索引时，MySQL将从最左开始选取一部分（767字符，最多到3072字符）字符串，将其内容存入到索引中。如果查询条件最左侧是可以匹配任意字符的通配符，无法定位具体的索引键值，优化器就会选择其他获取数据的方式而忽略索引的存在。因此，当带有索引的查询条件列是字符类型，如果使用模糊匹配操作符，不要将其放在最左侧，要放到第一个具体字符的右侧

九、补充：
数据库怎么优化查询效率？

储存引擎选择：如果数据表需要事务处理，应该考虑使用 InnoDB，因为它完全符合 ACID 特性。
如果不需要事务处理，使用默认存储引擎 MyISAM 是比较明智的
分表分库，主从。
对查询进行优化，要尽量避免全表扫描，首先应考虑在 where 及 order by 涉及的列上建立索
引
应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全
表扫描
应尽量避免在 where 子句中使用 != 或 <> 操作符，否则将引擎放弃使用索引而进行全表扫
描
应尽量避免在 where 子句中使用 or 来连接条件，如果一个字段有索引，一个字段没有索引，
将导致引擎放弃使用索引而进行全表扫描
Update 语句，如果只更改 1、2 个字段，不要 Update 全部字段，否则频繁调用会引起明显的
性能消耗，同时带来大量日志
对于多张大数据量（这里几百条就算大了）的表 JOIN，要先分页再 JOIN，否则逻辑读会很高，
性能很差。