《Mysql - SQL优化》

一：在查询语句时，应该注意的优化问题

　　- SELECT语句务必指明字段名称

　　　　- SELECT * 会增加很多不必要的消耗（CPU、IO、内存、网络带宽）

　　　　- 同时会让 Mysql 优化器无法优化

 

　　- 在确定数据集大小的情况下，使用 limit 指明 数据数量

　　　　- Mysql 是在先返回结果集之后再进行计算，然后抛弃其中大部分数据

 

　　- 筛选时注意字符类型

　　　　- 避免SQL 隐式转换，导致索引失效

 

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

　　　　- MySQL对于 In 做了相应的优化，即将 In 中的常量全部存储在一个数组里面，而且这个数组是排好序的。

　　　　- 但是如果数值较多，产生的消耗也是比较大的。

 

　　- 排序在任何时候的消耗都是昂贵的

　　　　- 尽量在需要排序的字段建立索引。

 

　　- 如果一定要使用 OR 的话

　　　　- 请在 OR 的两侧都加上索引

 

　　- 尽量用 union all 代替 union

　　　　- union 和 union all的差异主要是前者需要将结果集合并后再进行唯一性过滤操作，这就会涉及到排序，增加大量的CPU运算，加大资源消耗及延迟。

　　　　- 当然，union all的前提条件是两个结果集没有重复数据。

 

　　- 避免在 where 子句中对字段进行 null 值判断

　　　　- 对于 null 的判断会导致引擎放弃使用索引而进行全表扫描。

 

　　- 注意范围查询语句

　　　　- 对于联合索引来说，如果存在范围查询，比如between、>、<等条件时，会造成后面的索引字段失效。

 

　　- 模糊匹配的时候%不要在头部

　　　　- 会导致索引列的失效

 

　　- 关联查询

　　　　- 确保关联查询的 ON 键上都有索引

 

二 ：Count( ) 优化

　  - 概述

　　　　- 通常来说，Count() 都需要扫描大量的行，才能获得精确的数据，因此优化是困难的。

　　　　-  ‘快速/精确/实现简单’，三者只能满足其二。必须舍弃掉一个。

 

　  - Count 真正的作用

　　　　- 统计某个列值的数量(不为null)

　　　　- 统计结果集行数

　　　　　　-  当Mysql确认括号内的表达式不可能为空时，实际上就是在统计行数.

　　　　　　-  最简单的就是当我们使用 Count(*) 时候，这种时候通配符 * 并不会像我们猜想那样扩展成所有列，而是直接统计所有行数。

　　

　　- 常见的问题是

　　　　-  在括号内指定了列却希望统计结果集的行数。 如果你希望知道的是结果集的行数，请使用Count(*),这样最清晰，性能也会很好。

　　

　　- 关于MyISAM 的 Count 神话

　　　　- 在 没有任何 Where 的条件下， Count(*) 才是很快的。

　　　　- 当存在 Where 的字句时候，就和其他引擎没什么区别了。

　　

　　- 优化方案

　　　　- 可以使用近似值 EXPLAIN 获取近似值，但是，他可能是不准确的。

　　　　- 可以使用 Redis / memcache 缓存数量。

　　　　- 建立汇总表，维护数量。