ThinkChat2.0新版上线,更智能更精彩,支持会话、画图、阅读、搜索等,送10W Token,即刻开启你的AI之旅 广告
## Mysql通过索引提升查询效率 ## 1\. 索引基本知识概览 ![](https://img.kancloud.cn/1a/fd/1afdfb5c0e2f7fb0f571fe3e18a3a255_1444x812.jpg) ##### 索引的优点 1、大大减少了服务器需要扫描的数据量 2、帮助服务器避免排序和临时表 3、将随机io变成顺序io ##### 索引的用处 1、快速查找匹配WHERE子句的行 2、从consideration中消除行,如果可以在多个索引之间进行选择,mysql通常会使用找到最少行的索引 3、如果表具有多列索引,则优化器可以使用索引的任何最左前缀来查找行 4、当有表连接的时候,从其他表检索行数据 5、查找特定索引列的min或max值 6、如果排序或分组时在可用索引的最左前缀上完成的,则对表进行排序和分组 7、在某些情况下,可以优化查询以检索值而无需查询数据行 ##### 索引的分类 主键索引/唯一索引/普通索引/全文索引/组合索引 ##### 常用优化原则 回表/覆盖索引/最左匹配/索引下推 ##### 索引采用的数据结构 哈希表/B+树/索引匹配方式 create table staffs( id int primary key auto\_increment, name varchar(24) not null default '' comment '姓名', age int not null default 0 comment '年龄', pos varchar(20) not null default '' comment '职位', add\_time timestamp not null default current\_timestamp comment '入职时间' ) charset utf8 comment '员工记录表'; \-----------alter table staffs add index idx\_nap(name, age, pos); ##### 全值匹配 全值匹配指的是和索引中的所有列进行匹配 explain select \* from staffs where name = 'July' and age = '23' and pos = 'dev'; ##### 匹配最左前缀 只匹配前面的几列 explain select \* from staffs where name = 'July' and age = '23'; explain select \* from staffs where name = 'July'; ##### 匹配列前缀 可以匹配某一列的值的开头部分 explain select \* from staffs where name like 'J%'; explain select \* from staffs where name like '%y'; ##### 匹配范围值 可以查找某一个范围的数据 explain select \* from staffs where name > 'Mary'; 精确匹配某一列并范围匹配另外一列 可以查询第一列的全部和第二列的部分 explain select \* from staffs where name = 'July' and age > 25; ##### 只访问索引的查询 查询的时候只需要访问索引,不需要访问数据行,本质上就是覆盖索引 explain select name,age,pos from staffs where name = 'July' and age = 25 and pos = 'dev'; ## 2\. HASH索引相关 ![](https://img.kancloud.cn/3d/e0/3de0a8894e2d7723b9e2ddbf5002c0cc_1316x256.jpg) ##### 哈希索引 基于哈希表的实现,只有精确匹配索引所有列的查询才有效 在mysql中,只有memory的存储引擎显式支持哈希索引 哈希索引自身只需存储对应的hash值,所以索引的结构十分紧凑,这让哈希索引查找的速度非常快 ##### 哈希索引的限制 1、哈希索引只包含哈希值和行指针,而不存储字段值,索引不能使用索引中的值来避免读取行 2、哈希索引数据并不是按照索引值顺序存储的,所以无法进行排序 3、哈希索引不支持部分列匹配查找,哈希索引是使用索引列的全部内容来计算哈希值 4、哈希索引支持等值比较查询,也不支持任何范围查询 5、访问哈希索引的数据非常快,除非有很多哈希冲突,当出现哈希冲突的时候,存储引擎必须遍历链表中的所有行指针,逐行进行比较,直到找到所有符合条件的行 6、哈希冲突比较多的话,维护的代价也会很高 ##### SQL案例 当需要存储大量的URL,并且根据URL进行搜索查找,如果使用B+树,存储的内容就会很大 select id from url where url="" 也可以利用将url使用CRC32做哈希,可以使用以下查询方式: select id fom url where url="" and url\_crc=CRC32("") 此查询性能较高原因是使用体积很小的索引来完成查找 ## 3\. 组合索引 ##### 组合索引 当包含多个列作为索引,需要注意的是正确的顺序依赖于该索引的查询,同时需要考虑如何更好的满足排序和分组的需要 ![](https://img.kancloud.cn/05/67/05673449b94addfcdcd9b16bf5e8c5a9_1256x234.jpg) 案例,建立组合索引a,b,c不同SQL语句使用索引情况 ![](https://img.kancloud.cn/14/9e/149eaafb64deb74961daabc316248eef_1226x397.jpg) ## 4\. 聚簇和非聚簇索引 ![](https://img.kancloud.cn/67/2d/672dc8debf2a9e29be686c63cb8e82d5_1625x259.jpg) ##### 聚簇索引与非聚簇索引 ##### 聚簇索引 不是单独的索引类型,而是一种数据存储方式,指的是数据行跟相邻的键值紧凑的存储在一起 优点 1、可以把相关数据保存在一起 2、数据访问更快,因为索引和数据保存在同一个树中 3、使用覆盖索引扫描的查询可以直接使用页节点中的主键值 缺点 1、聚簇数据最大限度地提高了IO密集型应用的性能,如果数据全部在内存,那么聚簇索引就没有什么优势 2、插入速度严重依赖于插入顺序,按照主键的顺序插入是最快的方式 3、更新聚簇索引列的代价很高,因为会强制将每个被更新的行移动到新的位置 4、基于聚簇索引的表在插入新行,或者主键被更新导致需要移动行的时候,可能面临页分裂的问题 5、聚簇索引可能导致全表扫描变慢,尤其是行比较稀疏,或者由于页分裂导致数据存储不连续的时候 ##### 非聚簇索引 数据文件跟索引文件分开存放 ## 5.覆盖索引 ![](https://img.kancloud.cn/f4/91/f491b47d8a6b7c9f39b985fe95881c6c_1377x230.jpg) ##### 覆盖索引 基本介绍 1、如果一个索引包含所有需要查询的字段的值,我们称之为覆盖索引 2、不是所有类型的索引都可以称为覆盖索引,覆盖索引必须要存储索引列的值 3、不同的存储实现覆盖索引的方式不同,不是所有的存储引擎都支持覆盖索引,memory不支持覆盖索引 优势 1、索引条目通常远小于数据行大小,如果只需要读取索引,那么mysql就会极大的较少数据访问量 2、因为索引是按照列值顺序存储的,所以对于IO密集型的范围查询会比随机从磁盘读取每一行数据的IO要少的多 3、一些存储引擎如MYISAM在内存中只缓存索引,数据则依赖于操作系统来缓存,因此要访问数据需要一次系统调用,这可能会导致严重的性能问题 4、由于INNODB的聚簇索引,覆盖索引对INNODB表特别有用 ##### 案例演示 1、当发起一个被索引覆盖的查询时,在explain的extra列可以看到using index的信息,此时就使用了覆盖索引 ![](https://img.kancloud.cn/30/d4/30d41b73c6364e8997a1928288068be4_1753x408.jpg) 2、在大多数存储引擎中,覆盖索引只能覆盖那些只访问索引中部分列的查询。不过,可以进一步的进行优化,可以使用innodb的二级索引来覆盖查询。 例如:actor使用innodb存储引擎,并在last\_name字段又二级索引,虽然该索引的列不包括主键actor\_id,但也能够用于对actor\_id做覆盖查询 ![](https://img.kancloud.cn/d9/03/d903a53d173bf37f7a06433e7b364c7c_1535x431.jpg) ## 6\. 常见优化处理落地方案 ![](https://img.kancloud.cn/2f/ca/2fca90314727d8761b05784afc799e4f_1600x618.jpg) #### 常见优化方案 #### 1.当使用索引列进行查询的时候尽量不要使用表达式,把计算放到业务层而不是数据库层 select actor\_id from actor where actor\_id=4; select actor\_id from actor where actor\_id+1=5; #### 2.尽量使用主键查询,而不是其他索引,因此主键查询不会触发回表查询 #### 3.使用前缀索引 有时候需要索引很长的字符串,这会让索引变的大且慢,通常情况下可以使用某个列开始的部分字符串,这样大大的节约索引空间,从而提高索引效率,但这会降低索引的选择性,索引的选择性是指不重复的索引值和数据表记录总数的比值,范围从1/#T到1之间。索引的选择性越高则查询效率越高,因为选择性更高的索引可以让mysql在查找的时候过滤掉更多的行。 一般情况下某个列前缀的选择性也是足够高的,足以满足查询的性能,但是对应BLOB,TEXT,VARCHAR类型的列,必须要使用前缀索引,因为mysql不允许索引这些列的完整长度,使用该方法的诀窍在于要选择足够长的前缀以保证较高的选择性,通过又不能太长。 案例演示: ~~~csharp --创建数据表 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; --计算完成之后可以创建前缀索引 alter table citydemo add key(city(7)); --注意:前缀索引是一种能使索引更小更快的有效方法,但是也包含缺点:mysql无法使用前缀索引做order by 和 group by。 ~~~ #### 4.使用索引扫描来排序 mysql有两种方式可以生成有序的结果:通过排序操作或者按索引顺序扫描,如果explain出来的type列的值为index,则说明mysql使用了索引扫描来做排序 扫描索引本身是很快的,因为只需要从一条索引记录移动到紧接着的下一条记录。但如果索引不能覆盖查询所需的全部列,那么就不得不每扫描一条索引记录就得回表查询一次对应的行,这基本都是随机IO,因此按索引顺序读取数据的速度通常要比顺序地全表扫描慢 mysql可以使用同一个索引即满足排序,又用于查找行,如果可能的话,设计索引时应该尽可能地同时满足这两种任务。 只有当索引的列顺序和order by子句的顺序完全一致,并且所有列的排序方式都一样时,mysql才能够使用索引来对结果进行排序,如果查询需要关联多张表,则只有当orderby子句引用的字段全部为第一张表时,才能使用索引做排序。order by子句和查找型查询的限制是一样的,需要满足索引的最左前缀的要求,否则,mysql都需要执行顺序操作,而无法利用索引排序 ~~~csharp --sakila数据库中rental表在rental_date,inventory_id,customer_id上有rental_date的索引 --使用rental_date索引为下面的查询做排序 explain select rental_id,staff_id from rental where rental_date='2005-05-25' order by inventory_id,customer_id\G *************************** 1. row *************************** id: 1 select_type: SIMPLE table: rental partitions: NULL type: ref possible_keys: rental_date key: rental_date key_len: 5 ref: const rows: 1 filtered: 100.00 Extra: Using index condition 1 row in set, 1 warning (0.00 sec) --order by子句不满足索引的最左前缀的要求,也可以用于查询排序,这是因为所以你的第一列被指定为一个常数 --该查询为索引的第一列提供了常量条件,而使用第二列进行排序,将两个列组合在一起,就形成了索引的最左前缀 explain select rental_id,staff_id from rental where rental_date='2005-05-25' order by inventory_id desc\G *************************** 1. row *************************** id: 1 select_type: SIMPLE table: rental partitions: NULL type: ref possible_keys: rental_date key: rental_date key_len: 5 ref: const rows: 1 filtered: 100.00 Extra: Using where 1 row in set, 1 warning (0.00 sec) --下面的查询不会利用索引 explain select rental_id,staff_id from rental where rental_date>'2005-05-25' order by rental_date,inventory_id\G *************************** 1. row *************************** id: 1 select_type: SIMPLE table: rental partitions: NULL type: ALL possible_keys: rental_date key: NULL key_len: NULL ref: NULL rows: 16005 filtered: 50.00 Extra: Using where; Using filesort --该查询使用了两中不同的排序方向,但是索引列都是正序排序的 explain select rental_id,staff_id from rental where rental_date>'2005-05-25' order by inventory_id desc,customer_id asc\G *************************** 1. row *************************** id: 1 select_type: SIMPLE table: rental partitions: NULL type: ALL possible_keys: rental_date key: NULL key_len: NULL ref: NULL rows: 16005 filtered: 50.00 Extra: Using where; Using filesort 1 row in set, 1 warning (0.00 sec) --该查询中引用了一个不再索引中的列 explain select rental_id,staff_id from rental where rental_date>'2005-05-25' order by inventory_id,staff_id\G *************************** 1. row *************************** id: 1 select_type: SIMPLE table: rental partitions: NULL type: ALL possible_keys: rental_date key: NULL key_len: NULL ref: NULL rows: 16005 filtered: 50.00 Extra: Using where; Using filesort 1 row in set, 1 warning (0.00 sec) ~~~ union all,in,or都能够使用索引,但是推荐使用in explain select \* from actor where actor\_id = 1 union all select \* from actor where actor\_id = 2; explain select \* from actor where actor\_id in (1,2); explain select \* from actor where actor\_id = 1 or actor\_id =2; ##### 5.范围列可以用到索引 范围条件是: 范围列可以用到索引,但是范围列后面的列无法用到索引,索引最多用于一个范围列 强制类型转换会全表扫描 create table user(id int,name varchar(10),phone varchar(11)); alter table user add index idx\_1(phone); ##### 不会触发索引 explain select \* from user where phone=13800001234; ##### 触发索引 explain select \* from user where phone='13800001234'; #### 常见总结使用规则 1.更新十分频繁,数据区分度不高的字段上不宜建立索引 2.更新会变更B+树,更新频繁的字段建议索引会大大降低数据库性能 3.类似于性别这类区分不大的属性,建立索引是没有意义的,不能有效的过滤数据, 4.一般区分度在80%以上的时候就可以建立索引,区分度可以使用 count(distinct(列名))/count(\*) 来计算 5.创建索引的列,不允许为null,可能会得到不符合预期的结果 6.当需要进行表连接的时候,最好不要超过三张表,因为需要join的字段,数据类型必须一致 7.能使用limit的时候尽量使用limit 8.单表索引建议控制在5个以内 9.单索引字段数不允许超过5个(组合索引) #### 创建索引的时候应该避免以下错误概念 1.索引越多越好 2.过早优化,在不了解系统的情况下进行优化 ## 7.索引监控 ![](https://img.kancloud.cn/1e/eb/1eeb01a7df08a488e099c2f4b9a228d2_1044x231.jpg) #### 索引监控 show status like 'Handler\_read%'; #### 参数解释 Handler\_read\_first:读取索引第一个条目的次数 Handler\_read\_key:通过index获取数据的次数 Handler\_read\_last:读取索引最后一个条目的次数 Handler\_read\_next:通过索引读取下一条数据的次数 Handler\_read\_prev:通过索引读取上一条数据的次数 Handler\_read\_rnd:从固定位置读取数据的次数 Handler\_read\_rnd\_next:从数据节点读取下一条数据的次数 ## 8.索引优化实践案例 ~~~php 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', '2017-08-28 17:01:49'); INSERT INTO itdragon_order_list VALUES ('10001', '61525478BB371361Q', '18.88', '18.79', '1', '10', 'ok', 'ok', 'auto', '1', 'itdragon', '2017-08-18 17:01:50'); INSERT INTO itdragon_order_list VALUES ('10002', '5RT64180WE555861V', '20.18', '20.17', '1', '10', 'ok', 'ok', 'auto', '1', 'itdragon', '2017-09-08 17:01:49'); ~~~ ## 案例一 ~~~csharp 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的性能要高于ref explain 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"; ~~~ ## 案例二 ~~~csharp --创建复合索引 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; ~~~