mysql sql 优化 博客园_《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 缓存数量。

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