5.3高性能的索引策略《创建高性能的索引》(3.4.5未完待续)

先概括一下索引的策略: 

1)单列索引 

2)前缀索引 

3)多列索引 

4)选择合适索引顺序

5)聚簇索引 

6)覆盖索引

7)索引扫描进行排序

8)压缩索引

9)冗余和重复索引

11)索引和锁

一、单列索引

索引列必须独立,即不能是表达式或函数的一部分

无法正却使用索引:select actor_id from actor where actor_id+1=5;

select ... where TO_DAYS(CURRENT_DATE) - TO_DAYS(date_col)<=10;

二、前缀索引

索引的列很长,导致索引大且慢,只索引列开始的部分(某一列的前面几个字符),节省空间也加快速度,但降低索引的选择性(查出结果变多)。

alter tabel XXX add key (col(7)) 前7位索引

通过left前几位计算相应长度的选择性,越大越好

缺点:mysql无法使用前缀索引做GROUP BY和ORDER BY,也无法使用前缀索引做覆盖扫描。

六、覆盖索引

索引包含(或说覆盖)所有需要查询的字段的值,为覆盖索引。

只需扫描索引就能在索引的叶子节点中获得所有的数据,不需回表查询,提高性能。好处:

(1)减少数据访问量(索引条目通常小于数据行的大小),缓存的负载重要。

(2)IO密集型的范围查找会比随机从磁盘中读取每一行数据的IO要少得多、因为索引是按照列值顺序存储

例1:索引覆盖的查询时,在EXPLAIN的Extra列可以看到Usingi ndex的信息。  

5.3高性能的索引策略《创建高性能的索引》(3.4.5未完待续)_第1张图片

例2:索引无法覆盖该查询,有两个原因:

(1)查询所有的列,没有任何索引覆盖了所有的列。

(2)MySQL不能在索引中执行LIKE操作。

5.3高性能的索引策略《创建高性能的索引》(3.4.5未完待续)_第2张图片

例3:解决办法:延迟关联

5.3高性能的索引策略《创建高性能的索引》(3.4.5未完待续)_第3张图片
查询中找到匹配的prod_id

例4:InnoDB的二级索引叶子节点:包含了主键的值,可有效地利用这些“额外“主键来覆盖查询。

sakila.actor使用InnoDB存储引擎,并在last_name字段有二级索引,索引不包含主键actor_id,也能覆盖查询:

5.3高性能的索引策略《创建高性能的索引》(3.4.5未完待续)_第4张图片

七、索引扫描进行排序

EXPLAIN出来的type列的值为“index“,则说明MySQL使用索引扫描来做排序(不要和Extra列的“Using index”搞混淆了)

(1)索引列顺序与order by子句顺序完全一致:顺/逆序,满足最左前缀要求

(2)关联多张表order by字段必须是第一张表

5.3高性能的索引策略《创建高性能的索引》(3.4.5未完待续)_第5张图片
没满足最左前缀要求

改进:WHERE rental_date = ‘2005-05-25’ ORDER BY inventory_id DESC;   使用第二列进行排序,将两列组合在一起

           WHERE rental_date > ‘2005-05-25’ ORDER BY rental_date, inventory_id;

错误:

排序不同:WHERE rental_date = ‘2005-05-25’ ORDER BY inventory_id DESC , customer_id ASC;

引用不在索引中的列:WHERE rental_date = ‘2005-05-25’ ORDER BY inventory_id , staff_id;

无法组合成索引的最左前缀: WHERE rental_date = ‘2005-05-25’ ORDER BY customer_id;

范围条件无法使用索引的其余列:WHERE rental_date = ‘2005-05-25’ ORDER BY inventory_id , customer_id;

                                                          WHERE rental_date = ‘2005-05-25’ AND inventory_id IN(1,2) ORDER BY customer_id;

关联的第二张表:

5.3高性能的索引策略《创建高性能的索引》(3.4.5未完待续)_第6张图片

八、压缩索引

虽然节省空间,但遍历花很多时间

方法:完全保存一个值,其他值和第一个值进行比较得不同后缀部分,例:第一个“perform“,第二个”performance“,”7,ance“这样的形式。

无法二分查找,只能从头开始。正序扫描速度还不错,倒序ORDER BY DESC不好

适用I/O密集型应用;对于CPU密集型更慢(压缩索引需要在CPU内存资源与磁盘之间做权衡

CREATE TABLE语句中指定PACK_KEYS参数来控制索引压缩的方式。

九、冗余和重复索引

相同列上创建多个索引,影响性能。三个重复的索引:

CREATE TABLE test(

    ID INT NOT NULL PRIMARY KEY, //主键限制

    A INT NOT NULL,

    B INT NOT NULL,

    UNIQUE(ID),  //唯一限制

    INDEX(ID) //索引

) ENGINE=InnoDB;

1.冗余索引:(1)索引(A,B),再创建索引(A)就是

                  (2)(A,ID),ID是主键,因为InnoDB来说主键列已经包含在二级索引中

2.不是冗余索引:创建索引(B,A),索引(B)也不是,不是索引(A,B)的最左前缀。或不同类型的索引

3.例:userinfo表。1000000行,每个state_id值大概有20000条记录。state_id列有一个索引对下面的查询有用:

Q1:SELECT count(*) FROM userinfo WHERE state_Id=5;  115次(QPS)

Q2SELECT state_id,city,address FROM userinfo WHERE state_id=5;  QPS小于10

扩展索引为(state_id,city,address),覆盖查询:

ALTER TABLE userinfo DROP KEY state_id, ADD KEY state_id_2(state_id,city,address);

Q2得更快了,Q1却变慢了

4.大多数情况下不需要冗余索引,删除掉,尽量扩展不是创建新索引,增加新索引将会导致INSERT、UPDATE、DELETE等操作的速度变慢

十一、索引和锁

锁定超过需要的行会增加锁争用减少并发性

InnoDB只访问行才加锁

5.3高性能的索引策略《创建高性能的索引》(3.4.5未完待续)_第7张图片

获取了1~4之间的行的排他锁。InnoDB锁住第1行

5.3高性能的索引策略《创建高性能的索引》(3.4.5未完待续)_第8张图片

EXPLAIN的Extra列出现了”Using where“,表示MySQL服务器将存储引擎返回行以后再应用WHERE过滤条件

这个查询挂起,直到释放第1行的锁

InnoDB、索引和锁有一些很少有人知道的细节:InnoDB在二级索引上使用共享(读)锁,但访问主键索引需要排他(写)锁。消除了使用覆盖索引的可能性,使SELECT FOR UPDATELOCK IN SHARE MODE非锁定查询要慢得多。

你可能感兴趣的:(5.3高性能的索引策略《创建高性能的索引》(3.4.5未完待续))