mysql 判断性别_MySQL性能调优（二）

当使用索引列查询的时候，尽量不要使用表达式，应该把计算放到业务层而不是数据库层。

例如下面这两个sql语句，显然应该避免的是第二种 where字句后面 写计算的

通过执行计划可以看出这个sql的type是const

而这个写表达式的是 index，const比index执行效率高

---

尽量使用主键查询，而不是其他索引，因为主键查询不会触发回表。

使用索引扫描来做排序：

mysql有两种方式可以生成有序的结果：通过排序操作或者按索引顺序扫描，如果explain出来的type列的值为index,则说明mysql使用了索引扫描来做排序

扫描索引本身是很快的，因为只需要从一条索引记录移动到紧接着的下一条记录。但如果索引不能覆盖查询所需的全部列，那么就不得不每扫描一条索引记录就得回表查询一次对应的行，这基本都是随机IO，因此按索引顺序读取数据的速度通常要比顺序地全表扫描慢

mysql可以使用同一个索引即满足排序，又用于查找行，如果可能的话，设计索引时应该尽可能地同时满足这两种任务。

只有当索引的列顺序和order by子句的顺序完全一致，并且所有列的排序方式都一样时（都是desc或都是asc），mysql才能够使用索引来对结果进行排序，如果查询需要关联多张表，则只有当orderby子句引用的字段全部为第一张表时，才能使用索引做排序。order by子句和查找型查询的限制是一样的，需要满足索引的最左前缀的要求，否则，mysql都需要执行顺序操作，而无法利用索引排序。

union all , in , or 都能使用索引的情况下，推荐使用 in

更新十分频繁，数据区分度不高的字段不宜建立索引：

更新会变更B+树，更新频繁的字段建立索引会大大降低数据库性能，更新的话会造成页分裂和页合并。

类似于性别这类区分度不大的属性，建立索引是没有意义的，不能有效过滤数据，想一下，性别就男和女，本身就能区分数据了，建立索引没什么意义，索引在id这种字段上建立的话，sql上where id = ? 这种的话，是直接可以检索的，而在性别上，就一个分支，男和女，没有太多的树。一般区分度在80%以上的时候就可以建立索引，区分度可以使用count(distinct(列名))/count(*)来计算。

创建索引的列，不允许为null。如果为null则会出现不符合预期的结果。

如果明确知道只有一条结果返回，limit 1 能够提高效率。因为用了limit 1之后 索引指针不会往下进行判断，如果下面还有数据，如果没有用limit 1 的话，还是会继续往下判断的。