索引基本知识
索引匹配方式
哈希索引
当需要存储大量的URL,并且根据URL进行搜索查找,如果使用B+树,存储的内容就会很大
select id from url where url=""
也可以利用将url使用CRC32做哈希,可以使用以下查询方式:
select id fom url where url="" and url_crc=CRC32("")
此查询性能较高原因是使用体积很小的索引来完成查找
组合索引
当包含多个列作为索引,需要注意的是正确的顺序依赖于该索引的查询,同时需要考虑如何更好的满足排序和分组的需要
案例,建立组合索引a,b,c,不同SQL语句使用索引情况:
where a=3 and b>10 and c=7
只使用索引a,b,因为b是范围查找,范围查找的后面就无法做精确匹配了,所以无论后面的c是否加过索引,都不走索引了。
where a=3 and b=10 and c=7
,就可以走索引a,b,c了。
建立索引的时候,尽量选择长度较小的列,占用存储空间较小。
簇族索引、非簇族索引
innodb是簇族索引
myisam是非簇族索引
聚簇索引,是为了减少对磁盘的IO。
为什么按照主键的顺序插入是最快的方式:因为如果不按顺序插入/删除,会产生过多的页分裂/合并,影响效率。(类似于大数据的region分割)
覆盖索引
1、当发起一个被索引覆盖的查询时,在explain的extra
列可以看到using index
的信息,此时就使用了覆盖索引
mysql> explain select store_id,film_id from inventory\G*************************** 1. row ***************************id: 1select_type: SIMPLEtable: inventorypartitions: NULLtype: indexpossible_keys: NULLkey: idx_store_id_film_idkey_len: 3ref: NULLrows: 4581filtered: 100.00Extra: Using index1 row in set, 1 warning (0.01 sec)
2、在大多数存储引擎中,覆盖索引只能覆盖那些只访问索引中部分列的查询。不过,可以进一步的进行优化,可以使用innodb的二级索引来覆盖查询。
例如:actor使用innodb存储引擎,并在last_name字段又二级索引,虽然该索引的列不包括主键actor_id,但也能够用于对actor_id做覆盖查询
mysql> explain select actor_id,last_name from actor where last_name='HOPPER'\G*************************** 1. row ***************************id: 1select_type: SIMPLEtable: actorpartitions: NULLtype: refpossible_keys: idx_actor_last_namekey: idx_actor_last_namekey_len: 137ref: constrows: 2filtered: 100.00Extra: Using index1 row in set, 1 warning (0.00 sec)
示例:出现了覆盖索引,显示using index
优化小细节
避免where id+1=5
这种查询,应该直接使用where id=4
type列的好坏排序:
system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL
前缀索引实例说明
有时候需要索引很长的字符串,这会让索引变的大且慢,通常情况下可以使用某个列开始的部分字符串,这样大大的节约索引空间,从而提高索引效率,但这会降低索引的选择性。
索引的选择性是指不重复的索引值和数据表记录总数的比值,范围从1/#T到1之间。索引的选择性越高则查询效率越高,因为选择性更高的索引可以让mysql在查找的时候过滤掉更多的行。
一般情况下某个列前缀的选择性也是足够高的,足以满足查询的性能,但是对应BLOB,TEXT,VARCHAR类型的列,必须要使用前缀索引,因为mysql不允许索引这些列的完整长度,使用该方法的诀窍在于要选择足够长的前缀以保证较高的选择性,通过又不能太长。
案例演示:
--创建数据表create table citydemo(city varchar(50) not null);insert into citydemo(city) select city from city;--重复执行5次下面的sql语句insert into citydemo(city) select city from citydemo;--更新城市表的名称update citydemo set city=(select city from city order by rand() limit 1);--查找最常见的城市列表,发现每个值都出现45-65次,select count(*) as cnt,city from citydemo group by city order by cnt desc limit 10;--查找最频繁出现的城市前缀,先从3个前缀字母开始,发现比原来出现的次数更多,可以分别截取多个字符查看城市出现的次数select count(*) as cnt,left(city,3) as pref from citydemo group by pref order by cnt desc limit 10;select count(*) as cnt,left(city,7) as pref from citydemo group by pref order by cnt desc limit 10;--此时前缀的选择性接近于完整列的选择性--还可以通过另外一种方式来计算完整列的选择性,可以看到当前缀长度到达7之后,再增加前缀长度,选择性提升的幅度已经很小了select count(distinct left(city,3))/count(*) as sel3,count(distinct left(city,4))/count(*) as sel4,count(distinct left(city,5))/count(*) as sel5,count(distinct left(city,6))/count(*) as sel6,count(distinct left(city,7))/count(*) as sel7,count(distinct left(city,8))/count(*) as sel8 from citydemo;--计算完成之后可以创建前缀索引,只取前7个字节创建索引,节省索引的存储空间alter table citydemo add key(city(7));--注意:前缀索引是一种能使索引更小更快的有效方法,但是也包含缺点:mysql无法使用前缀索引做order by 和 group by。
OLTP/OLAP
基数cardinality统计
Hyperloglog算法
基数越小,关联的时候效率越高
使用索引扫描来做排序
mysql有两种方式可以生成有序的结果:通过排序操作或者按索引顺序扫描,如果explain出来的type列的值为index,则说明mysql使用了索引扫描来做排序
扫描索引本身是很快的,因为只需要从一条索引记录移动到紧接着的下一条记录。但如果索引不能覆盖查询所需的全部列,那么就不得不每扫描一条索引记录就得回表查询一次对应的行,这基本都是随机IO,因此按索引顺序读取数据的速度通常要比顺序地全表扫描慢
mysql可以使用同一个索引即满足排序,又用于查找行,如果可能的话,设计索引时应该尽可能地同时满足这两种任务。
只有当索引的列顺序和order by子句的顺序完全一致,并且所有列的排序方式都一样时,mysql才能够使用索引来对结果进行排序,如果查询需要关联多张表,则只有当orderby子句引用的字段全部为第一张表时,才能使用索引做排序。order by子句和查找型查询的限制是一样的,需要满足索引的最左前缀的要求,否则,mysql都需要执行顺序操作,而无法利用索引排序
--sakila数据库中rental表在rental_date,inventory_id,customer_id上有rental_date的索引--使用rental_date索引为下面的查询做排序explain select rental_id,staff_id from rental where rental_date='-05-25' order by inventory_id,customer_id\G*************************** 1. row ***************************id: 1select_type: SIMPLEtable: rentalpartitions: NULLtype: refpossible_keys: rental_datekey: rental_datekey_len: 5ref: constrows: 1filtered: 100.00Extra: Using index condition1 row in set, 1 warning (0.00 sec)--order by子句不满足索引的最左前缀的要求,也可以用于查询排序,这是因为所以你的第一列被指定为一个常数--该查询为索引的第一列提供了常量条件,而使用第二列进行排序,将两个列组合在一起,就形成了索引的最左前缀explain select rental_id,staff_id from rental where rental_date='-05-25' order by inventory_id desc\G*************************** 1. row ***************************id: 1select_type: SIMPLEtable: rentalpartitions: NULLtype: refpossible_keys: rental_datekey: rental_datekey_len: 5ref: constrows: 1filtered: 100.00Extra: Using where1 row in set, 1 warning (0.00 sec)--下面的查询不会利用索引explain select rental_id,staff_id from rental where rental_date>'-05-25' order by rental_date,inventory_id\G*************************** 1. row ***************************id: 1select_type: SIMPLEtable: rentalpartitions: NULLtype: ALLpossible_keys: rental_datekey: NULLkey_len: NULLref: NULLrows: 16005filtered: 50.00Extra: Using where; Using filesort--该查询使用了两中不同的排序方向,但是索引列都是正序排序的,在排序列能组成最左前缀匹配的情况下,可以全部正序,可以全部逆序,都能走索引,但是不能一个正序,一个逆序。explain select rental_id,staff_id from rental where rental_date>'-05-25' order by inventory_id desc,customer_id asc\G*************************** 1. row ***************************id: 1select_type: SIMPLEtable: rentalpartitions: NULLtype: ALLpossible_keys: rental_datekey: NULLkey_len: NULLref: NULLrows: 16005filtered: 50.00Extra: Using where; Using filesort1 row in set, 1 warning (0.00 sec)--该查询中引用了一个不再索引中的列explain select rental_id,staff_id from rental where rental_date>'-05-25' order by inventory_id,staff_id\G*************************** 1. row ***************************id: 1select_type: SIMPLEtable: rentalpartitions: NULLtype: ALLpossible_keys: rental_datekey: NULLkey_len: NULLref: NULLrows: 16005filtered: 50.00Extra: Using where; Using filesort1 row in set, 1 warning (0.00 sec)
索引监控
索引优化分析案例
预先准备好数据
SET FOREIGN_KEY_CHECKS=0;DROP TABLE IF EXISTS `itdragon_order_list`;CREATE TABLE `itdragon_order_list` (`id` bigint(11) NOT NULL AUTO_INCREMENT COMMENT '主键id,默认自增长',`transaction_id` varchar(150) DEFAULT NULL COMMENT '交易号',`gross` double DEFAULT NULL COMMENT '毛收入(RMB)',`net` double DEFAULT NULL COMMENT '净收入(RMB)',`stock_id` int(11) DEFAULT NULL COMMENT '发货仓库',`order_status` int(11) DEFAULT NULL COMMENT '订单状态',`descript` varchar(255) DEFAULT NULL COMMENT '客服备注',`finance_descript` varchar(255) DEFAULT NULL COMMENT '财务备注',`create_type` varchar(100) DEFAULT NULL COMMENT '创建类型',`order_level` int(11) DEFAULT NULL COMMENT '订单级别',`input_user` varchar(20) DEFAULT NULL COMMENT '录入人',`input_date` varchar(20) DEFAULT NULL COMMENT '录入时间',PRIMARY KEY (`id`)) ENGINE=InnoDB AUTO_INCREMENT=10003 DEFAULT CHARSET=utf8;INSERT INTO itdragon_order_list VALUES ('10000', '81X97310V32236260E', '6.6', '6.13', '1', '10', 'ok', 'ok', 'auto', '1', 'itdragon', '-08-28 17:01:49');INSERT INTO itdragon_order_list VALUES ('10001', '61525478BB371361Q', '18.88', '18.79', '1', '10', 'ok', 'ok', 'auto', '1', 'itdragon', '-08-18 17:01:50');INSERT INTO itdragon_order_list VALUES ('10002', '5RT64180WE555861V', '20.18', '20.17', '1', '10', 'ok', 'ok', 'auto', '1', 'itdragon', '-09-08 17:01:49');
逐步开始进行优化:
第一个案例:
select * from itdragon_order_list where transaction_id = "81X97310V32236260E";--通过查看执行计划发现type=all,需要进行全表扫描explain select * from itdragon_order_list where transaction_id = "81X97310V32236260E";--优化一、为transaction_id创建唯一索引create unique index idx_order_transaID on itdragon_order_list (transaction_id);--当创建索引之后,唯一索引对应的type是const,通过索引一次就可以找到结果,普通索引对应的type是ref,表示非唯一性索引赛秒,找到值还要进行扫描,直到将索引文件扫描完为止,显而易见,const的性能要高于refexplain select * from itdragon_order_list where transaction_id = "81X97310V32236260E";--优化二、使用覆盖索引,查询的结果变成 transaction_id,当extra出现using index,表示使用了覆盖索引explain select transaction_id from itdragon_order_list where transaction_id = "81X97310V32236260E";
第二个案例
--创建复合索引create index idx_order_levelDate on itdragon_order_list (order_level,input_date);--创建索引之后发现跟没有创建索引一样,都是全表扫描,都是文件排序explain select * from itdragon_order_list order by order_level,input_date;--可以使用force index强制指定索引explain select * from itdragon_order_list force index(idx_order_levelDate) order by order_level,input_date;--其实给订单排序意义不大,给订单级别添加索引意义也不大,因此可以先确定order_level的值,然后再给input_date排序explain select * from itdragon_order_list where order_level=3 order by input_date;