Loading... # mysql调优(三) ## 通过索引进行优化 ### 索引的基本知识 索引的优点 1. 大大减少了服务器需要扫描的数据量 2. 帮助服务器避免排序和临时表 3. 将随机io变成顺序io 索引的用处 1. 快速查找匹配WHERE子句的行 2. 从consideration中消除行,如果可以在多个索引之间进行选择，mysql通常会使用找到最少行的索引 3. 如果表具有多列索引，则优化器可以使用索引的任何最左前缀来查找行 4. 当有表连接的时候，从其他表检索行数据 5. 查找特定索引列的min或max值 6. 如果排序或分组时在可用索引的最左前缀上完成的，则对表进行排序和分组 7. 在某些情况下，可以优化查询以检索值而无需查询数据行 索引的分类 - 主键索引 - 唯一索引 - 普通索引 - 全文索引 - 组合索引 索引采用的数据结构 大多数mysql的索引(主键、唯一、普通、全文)采用的是B+树，空间数据类型用的是R树，Memory存储引擎还支持哈希索引。 哈希表： 采用哈希表存储有如下缺点 1. 需要将所有的数据文件添加到内存，比较耗费内存空间 2. 如果所有的查询都是等值查询，那么哈希确实很快，但是在企业或者实际工作环境中，范围查找的数据更多，因此哈希就不合适了 B+数: 为什么要用B+树？因为无论二叉树还是红黑树，都会因为树的深度过深(每个节点至多有两个子节点)而造成io次数变多，影响数据读取的速率。因此，可以采用B树，即每个节点中可以包含多个key，与指向子节点的指针，可以拥有多个子节点，缺点是每个节点都有key，同时包含data，虽然查询时，命中当前的key就不需要继续向下遍历了，但是每个页存储空间有限，如果data比较大会造成每个节点存储key的数量变小，当存储量很大时，仍然会造成树的深度过深。所以，采用B+树，它与B树的区别是，普通节点不会存储data，所有data都存在叶子节点上，这样每个页存储的key数量增多，降低了树的高度，并将数据范围变为多个区间，区间越多，数据检索越快，理论上三层的B+树就可以存储千万级别的数据。叶子节点两两指针相互连接(符合磁盘的预读特性)，顺序查询性能更高。 ![Bplustrees.png][1] 在B+树上有两个头指针，一个指向根节点，另一个指向关键字最小的叶子节点，而且所有叶子节点(即数据节点)之间是一种链式环结构，因此可以对B+树进行两种查找运算，一种是对于主键的范围查找和分页查找，另一种是从根节点开始，进行随机查找。 ### 聚簇索引与非聚簇索引 聚簇索引 不是单独的索引类型，而是一种数据存储方式，指的是数据行跟相邻的键值紧凑的存储在一起 优点： 1. 可以把相关数据保存在一起 2. 数据访问更快，因为索引和数据保存在同一个树中 3. 使用覆盖索引扫描的查询可以直接使用页节点中的主键值 缺点: 1. 聚簇数据最大限度地提高了IO密集型应用的性能，如果数据全部在内存，那么聚簇索引就没有什么优势 2. 插入速度严重依赖于插入顺序，按照主键的顺序插入是最快的方式 3. 更新聚簇索引列的代价很高，因为会强制将每个被更新的行移动到新的位置 4. 基于聚簇索引的表在插入新行，或者主键被更新导致需要移动行的时候，可能面临页分裂的问题 5. 聚簇索引可能导致全表扫描变慢，尤其是行比较稀疏，或者由于页分裂导致数据存储不连续的时候 聚簇索引因为索引与数据在一个文件中，每次插入和删除操作都很能存在页分裂和页合并问题，即向某个页中插入新的key，超过了该页的存储上限时，这个页会分出一半数据,分裂成两个页。同样的，如果某两个页数据被删除，导致key减少，也会合并成一个页，造成io上的开销。 非聚簇索引 数据文件跟索引文件分开存放 InnoDB采用的是聚簇索引，默认对主键创建索引，如果没有主键，那么会选择唯一键，如果没有唯一键，那么会生成一个6位的row_id来作为主键,主键索引叶子节点存储的是该行的记录。如果创建索引的键是其他字段，那么在叶子节点中存储的是该记录的主键，然后再通过主键索引找到对应的记录，叫做回表。 MyISAM采用的是非聚簇索引，叶子节点中保存的是该条记录的地址，然后再通过地址去数据文件中找到对应的记录。 ### 技术名词 - 回表 在普通列创建索引时，叶子节点存储的并不是整行数据，而是对应的主键，如果需要取出该行的其他字段，需要再次通过主键索引获取该条记录，这个过程叫做回表 - 覆盖索引 在普通列创建索引时，比如，为name字段添加了索引，通过`SELECT id,name FROM table_name`来查询，因为id和name都可以通过该索引直接拿到，也就是不需要回表了，回表过程没有了，就叫做覆盖索引 - 最左匹配 在组合索引中，比如，我为name和age创建组合索引，此时name在左边，当我使用`SELECT * FROM table WHERE name='张三' AND age=20`进行查询时，会使用索引，但是如果我跳过name，使用`SELECT * FROM table WHERE age=20`时是不会使用索引的，最左比配，需要先匹配左边的，然后才能使用右边的，`SELECT * FROM table WHERE name='张三'`是会使用索引的。当组合索引中所有字段都在WHERE字句中的时候，mysql会自动优化，顺序无所谓，其他情况下必须保证最左匹配 - 索引下推 在组合索引中，比如，我为name和age创建组合索引，执行`SELECT * FROM table WHERE name='张三' AND age=20`时，在老版本中，会从存储引擎中先取出name等于张三的所有值，然后在server层过滤age。在高版本中，会在存储引擎中取name为张三的值的同时将age过滤掉，这就是索引下推 ### 索引匹配方式 创建测试表 ``` 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 * from staffs where name = 'July' and age > 25 and pos = 'dev';//范围查询之后的条件都不会用到索引，因此pos不会使用索引，语句中尽量只有一个范围条件，并且放在最后 ``` 只访问索引的查询 查询的时候只需要访问索引，不需要访问数据行，本质上就是覆盖索引 ``` explain select name,age,pos from staffs where name = 'July' and age = 25 and pos = 'dev'; ``` ### 哈希索引 基于哈希表的实现，只有精确匹配索引所有列的查询才有效,在mysql中，只有memory的存储引擎显式支持哈希索引,哈希索引自身只需存储对应的hash值，所以索引的结构十分紧凑，这让哈希索引查找的速度非常快。 哈希索引的限制 1. 哈希索引只包含哈希值和行指针，而不存储字段值，所以不能使用索引中的值来避免读取行 2. 哈希索引数据并不是按照索引值顺序存储的，所以无法进行排序 3. 哈希索引不支持部分列匹配查找，哈希索引是使用索引列的全部内容来计算哈希值 4. 哈希索引支持等值比较查询，但不支持任何范围查询 5. 访问哈希索引的数据非常快，除非有很多哈希冲突，当出现哈希冲突的时候，存储引擎必须遍历链表中的所有行指针，逐行进行比较，直到找到所有符合条件的行 6. 哈希冲突比较多的话，维护的代价也会很高 案例 当需要存储大量的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语句使用索引情况.png][2] ### 覆盖索引 基本介绍 1. 如果一个索引包含所有需要查询的字段的值，我们称之为覆盖索引 2. 不是所有类型的索引都可以称为覆盖索引，覆盖索引必须要存储索引列的值 3. 不同的存储实现覆盖索引的方式不同，不是所有的引擎都支持覆盖索引，memory不支持覆盖索引 优势 1. 索引条目通常远小于数据行大小，如果只需要读取索引，那么mysql就会极大的减少数据访问量 2. 因为索引是按照列值顺序存储的，所以对于IO密集型的范围查询会比随机从磁盘读取每一行数据的IO要少的多 3. 一些存储引擎如MYISAM在内存中只缓存索引，数据则依赖于操作系统来缓存，因此要访问数据需要一次系统调用，这可能会导致严重的性能问题 4. 由于INNODB的聚簇索引，覆盖索引对INNODB表特别有用 案例演示 当发起一个被索引覆盖的查询时，在explain的extra列可以看到using index的信息，此时就使用了覆盖索引 ``` mysql> explain select store_id,film_id from inventory\G *************************** 1. row *************************** id: 1 select_type: SIMPLE table: inventory partitions: NULL type: index possible_keys: NULL key: idx_store_id_film_id key_len: 3 ref: NULL rows: 4581 filtered: 100.00 Extra: Using index 1 row in set, 1 warning (0.01 sec) ``` 在大多数存储引擎中，覆盖索引只能覆盖那些只访问索引中部分列的查询。不过，可以进一步的进行优化，可以使用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: 1 select_type: SIMPLE table: actor partitions: NULL type: ref possible_keys: idx_actor_last_name key: idx_actor_last_name key_len: 137 ref: const rows: 2 filtered: 100.00 Extra: Using index 1 row in set, 1 warning (0.00 sec) ``` ### 优化小细节 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不允许索引这些列的完整长度，使用该方法的诀窍在于要选择足够长的前缀以保证较高的选择性，同时又不能太长。 案例演示： ``` --创建数据表 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出来的Extra列的值未出现Using filesort,则说明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='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) ``` 5、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; ``` 6、范围列可以用到索引 范围条件是：<、<=、>、>=、between,范围列可以用到索引，但是范围列后面的列无法用到索引，索引最多用于一个范围列 7、强制类型转换会全表扫描 ``` 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';//触发索引 ``` 8、更新十分频繁，数据区分度不高的字段上不宜建立索引 - 更新会变更B+树，更新频繁的字段建立索引会大大降低数据库性能 - 类似于性别这类区分不大的属性，建立索引是没有意义的，不能有效的过滤数据 - 一般区分度在80%以上的时候就可以建立索引，区分度可以使用 count(distinct(列名))/count(*) 来计算 9、创建索引的列，不允许为null，否则可能会得到不符合预期的结果 10、当需要进行表连接的时候，最好不要超过三张表，因为需要join的字段，数据类型必须一致 11、能使用limit的时候尽量使用limit 12、单表索引建议控制在5个以内 13、单索引字段数不允许超过5个（组合索引） 14、创建索引的时候应该避免以下错误概念 - 索引越多越好 - 过早优化，在不了解系统的情况下进行优化 ### 索引监控 ``` 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：从数据节点读取下一条数据的次数 其中主要关注Handler_read_key与Handler_read_rnd_next，越高越好。 ### 索引优化分析案例 预先准备好数据 ``` 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'); ``` 逐步开始进行优化： 第一个案例： ``` 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"; ``` 第二个案例 ``` --创建复合索引 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; ``` ## mysql join的方式 mysql采用Nested-Loop(嵌套循环)的方式进行join。 ### Simple Nested-Loop Join ![snlj.jpg][3] r为驱动表，s为匹配表，可以看到从r中分别取出每一个记录去匹配s表的列，然后再合并数据，对s表进行r表的行数次访问，对数据库的开销比较大。 ### Index Nested-Loop Join ![inlj.jpg][4] 这个要求非驱动表(匹配表s)上有索引，可以通过索引来减少比较，加速查询，在查询时，驱动表(r)会根据关联字段的索引进行查找，当在索引上找到符合的值，再回表进行查询，也就是只有当匹配到索引以后才会进行回表查询。如果非驱动表(s)的关联键是主键的话，性能会非常高，如果不是主键，要进行多次回表查询，先关联索引，然后根据二级索引的主键ID进行回表操作，性能上比索引是主键要慢。 ### Block Nested-Loop Join ![bnlj.jpg][5] 如果有索引，会选取Index Nested-Loop方式进行join，但如果join列没有索引，就会采用Block Nested-Loop Join。可以看到中间有个join buffer缓冲区，是将驱动表的结果缓存到join buffer中，然后批量与匹配表进行匹配，将Simple Nested-Loop的多次比较合并为一次，降低了非驱动表(s)的访问频率。默认情况下join_buffer_size=256k，在查找的时候mysql会将所有的需要的列缓存到join buffer当中，包括select的列，而不是仅仅缓存关联列。在一个有N个join关联的sql当中会在之行时候分配N-1个join buffer。 [1]: https://www.princelei.club/usr/uploads/2020/04/4170117126.png [2]: https://www.princelei.club/usr/uploads/2020/04/2081803158.png [3]: https://www.princelei.club/usr/uploads/2020/04/1374312384.jpg [4]: https://www.princelei.club/usr/uploads/2020/04/1283953870.jpg [5]: https://www.princelei.club/usr/uploads/2020/04/3388340984.jpg Last modification：June 11th, 2020 at 05:57 pm © 允许规范转载
