索引优化策略

Posted 2020-10-26 Mr.Aaron

1.高性能索引策略

对于innodb而言,因为节点下有数据文件,因此节点的分裂将会比较慢.

对于innodb的主键,尽量用整型,而且是递增的整型.如果是无规律的数据,将会产生的页的分裂,影响速度.

2. 索引覆盖

索引覆盖是指 如果查询的列恰好是索引的一部分,那么查询只需要在索引文件上进行,不需要回行到磁盘再找数据.

这种查询速度非常快,称为”索引覆盖”

3. 理想的索引

1:查询频繁 2:区分度高  3:长度小  4: 尽量能覆盖常用查询字段.

索引长度直接影响索引文件的大小,影响增删改的速度,并间接影响查询速度(占用内存多).

针对列中的值,从左往右截取部分,来建索引

1: 截的越短, 重复度越高,区分度越小, 索引效果越不好

2: 截的越长, 重复度越低,区分度越高, 索引效果越好,但带来的影响也越大--增删改变慢,并间影响查询速度.

 

所以, 我们要在  区分度 + 长度  两者上,取得一个平衡.

惯用手法: 截取不同长度,并测试其区分度,

 select count(distinct left(word,6))/count(*) from dict;

对于一般的系统应用: 区别度能达到0.1,索引的性能就可以接受.

对于左前缀不易区分的列 ,建立索引的技巧

如 url列

http://www.baidu.com

http://www.zixue.it

列的前11个字符都是一样的,不易区分, 可以用如下2个办法来解决

1: 把列内容倒过来存储,并建立索引

Moc.udiab.www//:ptth

Ti.euxiz.www//://ptth

这样左前缀区分度大,

 

2: 伪hash索引效果

同时存 url_hash列

 

3:多列索引

多列索引的考虑因素---  列的查询频率 , 列的区分度

4.索引与排序

排序可能发生2种情况:

1: 对于覆盖索引,直接在索引上查询时,就是有顺序的, using index

2: 先取出数据,形成临时表做filesort(文件排序,但文件可能在磁盘上,也可能在内存中)

 

我们的争取目标-----取出来的数据本身就是有序的! 利用索引来排序.

 

比如: goods商品表, (cat_id,shop_price)组成联合索引,

where cat_id=N order by shop_price ,可以利用索引来排序,

select goods_id,cat_id,shop_price from goods order by shop_price;

// using where,按照shop_price索引取出的结果,本身就是有序的.

 

select goods_id,cat_id,shop_price from goods order by click_count;

// using filesort 用到了文件排序,即取出的结果再次排序

5. 重复索引与冗余索引

重复索引

是指 在同1个列(如age), 或者 顺序相同的几个列(age,school), 建立了多个索引,

称为重复索引, 重复索引没有任何帮助,只会增大索引文件,拖慢更新速度, 去掉.

冗余索引

冗余索引是指2个索引所覆盖的列有重叠, 称为冗余索引

比如 x,m,列   , 加索引  index x(x),  index xm(x,m)

x,xm索引, 两者的x列重叠了,  这种情况,称为冗余索引.

甚至可以把 index mx(m,x) 索引也建立, mx, xm 也不是重复的,因为列的顺序不一样.

6. 索引碎片与维护

在长期的数据更改过程中, 索引文件和数据文件,都将产生空洞,形成碎片.

我们可以通过一个nop操作(不产生对数据实质影响的操作), 来修改表.

比如: 表的引擎为innodb

alter table 表名 engine innodb

optimize table 表名

注意: 修复表的数据及索引碎片,就会把所有的数据文件重新整理一遍,使之对齐.

这个过程,如果表的行数比较大,也是非常耗费资源的操作.

所以,不能频繁的修复.

如果表的Update操作很频率,可以按周/月,来修复.

如果不频繁,可以更长的周期来做修复.