一：在查询语句时，应该注意的优化问题
- 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 缓存数量。
- 建立汇总表，维护数量。