数据库索引调优技巧

前面介绍了数据库优化索引，这里我们介绍数据库索引调优

长字段的索引调优

使用组合索引的技巧

覆盖索引

排序优化

冗余、重复索引的优化

1、长字段的索引调优

selelct  *  from   employees where first_name = ' Facello'   假设 first_name 的字段长度很长，如大于200个字符，那么索引占用的空间也会很大，

作用在超长字段的索引查询效率也不高。

解决方法： 额外创建个字段，比如first_name_hash  int default 0 not null.  first_name的hashcode 

 insert into employees value (999999, now(), 'zhangsan...','zhang','M',now(), CRC32('zhangsan...'));

first_name_hash的值应该具备以下要求

1) 字段的长度应该比较小，SHA1和MD5是不合适的

2) 应当尽量避免hash冲突，就目前来说，流行使用CRC32(),或者FNV64()

修改后的SQL selelct  *  from   employees where first_name_hash = CRC32(zhangsan...)  and first_name = ' Facello' 

并且给 first_name_hash设置所有，并带上 first_name = ' Facello'  为了解决hash冲突也能返回正确的结果。

--长字段调优

selelct  *  from   employees where first_name like ' Facello%'  

如果是like，就不能使用上面的调优方法。

解决方法： 前缀索引

alter table employees  add  key (first_name(5))   这里的5是如何确定的，能不能其它数字呢？

索引选择性 = 不重复的索引值/数据表的总记录数

数值越大，表示选择性越高，性能越好。

select count(distince first_name)/count(*) from employees;   -- 返回的值为0。0043 完整列的选择性 0.0043 【这个字段的最大选择性】

select count(distinct left(first_name,5)) / count(*) from  employees;  -- 返回结果 0.0038
select count(distinct left(first_name,6)) / count(*) from  employees;  -- 返回结果 0.0041
select count(distinct left(first_name,7)) / count(*) from  employees;  -- 返回结果 0.0042
select count(distinct left(first_name,8)) / count(*) from  employees;  -- 返回结果 0.0042
select count(distinct left(first_name,9)) / count(*) from  employees;  -- 返回结果 0.0042
select count(distinct left(first_name,10)) / count(*) from  employees;  -- 返回结果 0.0042
select count(distinct left(first_name,11)) / count(*) from  employees;  -- 返回结果 0.0043，说明 为大于等于11时，返回 0.0043
select count(distinct left(first_name,12)) / count(*) from  employees;  -- 返回结果 0.0043

　说明 为大于等于11时，返回 0.0043

结论： 前缀索引的长度设置为11 

alter table employees  add  key (first_name(11))  

优点： 前缀索引可以让索引更小，更加高效，而且对上层应用是透明的。应用不需要做任何改造，使用成本较低。

这是一种比较容易落地的优化方案。

局限性： 无法做order by、group by； 无法使用覆盖索引。

使用场景： 后缀索引，MySql是没有后缀索引的

额外创建一个字段，比如说first_name_reverse, 在存储的时候，把first_name的值翻转过来再存储。

比方Facello 变成 ollecaF存储到first_name_reverse

2、单例索引 vs 组合索引

explain select *  from salaries where from_date = '1986-06-26'  and to_date = '1987-06-26';

salaries表没有索引， explain后type为All   All为全表扫描，查询时间为1s537ms

创建两个索引(单例索引)

 type为index_merge，

Extra为 Using intersect(salaries_to_date_index,salaries_from_date_index); Using where

查询时间为229ms

修改成组合索引index(from_date, to_date)

type : 为const  。说明组合索引比上面的单例索引性能好一些。

查询时间为215ms。 性能差异不大

总结： 

SQL存在多个条件，多个单列索引，会使用索引合并

如果出现索引合并，往往说明索引不够合理。

 如果SQL暂时没有性能问题，暂时可以不管。

组合索引要注意索引列顺序[最左前缀原则]

补充： 

3、覆盖索引

什么是覆盖索引：对应索引X，SELECT的字段只需从索引就能获得，而无需到表数据里获取，这样的索引就叫覆盖索引。

索引index(from_date, to_date)

索引无法覆盖查询字段时

explain select * from salaries where from_date = '1986-06-26' and to_date = '1987-06-26';

type: ref

rows: 86

extra: null

索引能覆盖查询字段时

explain select from_date, to_date from salaries where from_date = '1986-06-26' and to_date = '1987-06-26';

type: ref

rows: 86

extra: using index

使用覆盖索引时，并不会改变SQL的执行过程。但是extra会显示using index

总结：

覆盖索引能提交SQL的性能

Select尽量只返回想要的字段(使用覆盖索引，减少网络传输的开销)

4、重复索引

索引是有开销的。增删改的时候，索引的维护开销。索引越多，开销越大。条件允许的情况下，尽量少创建索引。

重复索引：

在相同的列上按照相同的顺序创建的索引。

create table test_table(
    id int not null primary key auto_increment,
    a int not null ,
    b int not null ,
    unique (id),
    index (id)
) ENGINE = InnoDB;

主键，唯一索引，普通索引。唯一索引在普通索引的基础上，增加了唯一性约束。主键在唯一索引的基础上增加了非空约束。相对于在Id的字段上创建了三个重复的索引。一般来说，重复索引是需要避免的。
如果发现有重复索引，也应该删掉重复索引。

上面发生了重复索引，改进方案：

create table test_table(
    id int not null primary key auto_increment,
    a int not null ,
    b int not null 
) ENGINE = InnoDB;　

删除唯一索引和普通索引，值保留主键索引。

5、冗余索引(针对B-Tree和B+Tree来说的)

如果已经存在索引index(A,B), 又创建了index(A), 那么index(A) 就是index(A,B)的冗余索引。

一般要避免冗余索引。但有特例，一定要避免掉进陷阱里。

explain select * from salaries where from_date = '1986-06-26' order by  emp_no;

索引index(from_date): type=ref  extra=null。 使用了索引。

索引index(from_date) 某种意义上来说就相当于index(from_date, emp_no)

修改索引index(from_date,to_date)再次执行：

explain select * from salaries where from_date = '1986-06-26' order by  emp_no;

索引index(from_date,to_date) type=ref  extra=Using filesort     说明order by子句无法使用索引。

索引index(from_date, to_date) 某种意义上来说就相当于index(from_date, to_date, emp_no), 不符合最左前缀原则，所以order by子句无法使用索引。

6、未使用的所有

某个索引根本未曾使用

累赘，删除。