数据局库的索引优化

1. B-tree索引以B+树的结构存储数据

2. B-tree索引能够加快数据的查询速度

3. B-tree索引更适合进行范围查找

1. 全职匹配的查询

2. 匹配最左前缀的查询

3. 匹配列前缀查询

4. 匹配范围值得查询

5. 精确匹配左前缀并范围匹配另外一列

6. 只访问索引的查询

7. 只访问索引查询

1. 如果不是按照索引的最左列开始查找，则无法使用索引

2. 使用索引时不能跳过索引中左边的列

3. not in和<>操作无法使用索引

4. 如果查询中有某个列的范围查询，则其右边所有列都无法使用索引

1. Hash索引时基于Hash表实现的，只有查询条件精确匹配Hash索引中的所有列时，才能够使用带hash索引

2. 对于Hash索引中的所有列，存储引擎都会为每一行计算一个Hash码，Hash索引中存储的就是Hash码

1. Hash索引必须进行二次查找

2. Hash索引无法用于排序

3. Hash索引不支持部分索引查找也不支持范围查找

4. Hash索引中的Hash码计算可能存在Hash冲突

- 索引大大减少了存储引擎需要扫描的数据量

- 索引可以帮助我们进行排序以避免使用临时表

- 索引可以把随机IO变为顺序IO




索引是不是越多越好???

- 索引会增加写操作的成本

- 太多的索引会增加查询优化器的选择时间

wget downloads.mysql.com/docs/sakila…

tar -zxf sakila-db.tar.gz

mysql -uroot -p < sakila-schema.sql

mysql -uroot -p < sakila-data.sql

索引列上不能使用表达式或者函数:


select ... from product where todays(out_date)-todays(current_date)<=30


select ...from product where out_date<=date_add(current_date,interval 30 day)



前缀索引和索引列的选择性:


create index index_name on table(col_name(n));

※ 索引的选择性是不重复索引值和表的记录数的比值



联合索引：


如何选择索引列的顺序：

1. 经常会被使用的列优先的原则

2. 选择性高的列优先原则

3. 宽度小的列优先原则



覆盖索引：


- 优点：

1. 可以优化缓存，减少磁盘IO操作

2. 可以减少随机IO，变随机IO操作为顺序IO

3. 可以避免对InnoDB主键索引的二次查询
4. 可以避免MyISAM表进行系统调用

- 缺点：

1. 存储引擎不支持覆盖索引（eg:memory)

2. 查询中使用了太多的列

3. 使用了双%号的like查询



使用索引来优化排序:

1. 通过排序操作

2. 按照索引顺序扫描数据

> 条件：

1. 索引的列顺序和order by子句的顺序完全一致

2. 索引中所有列的方向（升序，降序）和order by子句完全一致

3. order by中的字段全部在关联表中的第一张表中


使用Btree索引模拟Hash索引对查询进行优化：




alter table film add title_md5 varchar(32);



update film set title_md5 = md5(title);



create index idx_md5 on film(title_md5);



explain select * from film where title_md5=md5('EGG IGBY') and title='EGG IGBY';# [在不同版本的数据库中有可能不支持]

使用Btree索引模拟Hash索引对查询进行优化的限制：

1. 只能处理键值得全值匹配查找

2. 所使用的Hash函数决定着索引键的大小

通过使用索引优化锁

1. 索引可以减少锁定的行数

2. 索引可以加快处理速度，同时也加快了锁的释放



删除重复和冗余的索引：pt-duplicate-key-checker h=127.0.0.1

如何使用pt-duplicate-key-checker检查冗余索引链接

查找未被使用的索引：
通过SQL语句查询进行检查:

更新索引统计信息及减少索引碎片：analyze table table_name/optimize table table_name[使用不当时会导致锁表]