数据局库的索引优化
MySQL索引
MySQL的B-tree索引特色:
1. B-tree索引以B+树的结构存储数据
2. B-tree索引可以加快数据的查询速度
3. B-tree索引更适合进行范围查找
使用场景:
1. 全职匹配的查询
2. 匹配最左前缀的查询
3. 匹配列前缀查询
4. 匹配范围值得查询
5. 精确匹配左前缀并范围匹配另一列
6. 只访问索引的查询
7. 只访问索引查询
Btree索引的使用限制
1. 若是不是按照索引的最左列开始查找,则没法使用索引
2. 使用索引时不能跳过索引中左边的列
3. not in和<>操做没法使用索引
4. 若是查询中有某个列的范围查询,则其右边全部列都没法使用索引
MySQL的Hash索引特色:
1. Hash索引时基于Hash表实现的,只有查询条件精确匹配Hash索引中的全部列时,才可以使用带hash索引
2. 对于Hash索引中的全部列,存储引擎都会为每一行计算一个Hash码,Hash索引中存储的就是Hash码
Hash索引的使用限制:
1. Hash索引必须进行二次查找
2. Hash索引没法用于排序
3. Hash索引不支持部分索引查找也不支持范围查找
4. Hash索引中的Hash码计算可能存在Hash冲突
索引的做用:
- 索引大大减小了存储引擎须要扫描的数据量
- 索引能够帮助咱们进行排序以免使用临时表
- 索引能够把随机IO变为顺序IO
索引是否是越多越好???
- 索引会增长写操做的成本
- 太多的索引会增长查询优化器的选择时间
安装时演示的数据库:
索引的优化策略:
索引列上不能使用表达式或者函数:
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[使用不当时会致使锁表]