开心学习
当前位置：数据库 > > 正文

mysql索引的机制（Mysql索引选择以及优化详解）

时间：2021-10-14 00:14:39类别：数据库

mysql索引的机制

Mysql索引选择以及优化详解

索引模型

哈希表

有序数组：在等值查询和范围查询场景中的性能都非常优秀，但插入和删除数据需要进行数据移动，成本太高。因此，只适用于静态存储引擎

二叉平衡树：每个节点的左儿子小于父节点，父节点又小于右儿子，时间复杂度是 o(log(n))

多叉平衡树：索引不止存在内存中，还要写到磁盘上。为了让一个查询尽量少地读磁盘，就必须让查询过程访问尽量少的数据块。因此，要使用“n 叉”树。

b+tree

b-tree 与 b+tree

b-tree

mysql索引的机制（Mysql索引选择以及优化详解）

b+tree

mysql索引的机制（Mysql索引选择以及优化详解）

innodb 使用了 b+ 树索引模型。假设，我们有一个主键列为 id 的表，表中有字段 k，并且在 k 上有索引，如下所示：

mysql索引的机制（Mysql索引选择以及优化详解）

注意事项

  • ?
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
    		•
  • // 假设一个数据页16k、一行数据1k、索引间指针6字节、索引字段bigint类型(8字节)
  •  
  • // 索引个数
  • k = 16*1024/(8+6) =1170
  •  
  • // 单个叶子节点记录数
  • n = 16/1 = 16
  •  
  • // 三层b+记录数
  • v = k*k*n = 21902400
    		•

    myisam也是使用b+tree索引，区别在于不区分主键和非主键索引，均是非聚簇索引，叶子节点保存的是数据文件的指针

    索引选择

    优化器选择索引的目的，是找到一个最优的执行方案，并用最小的代价去执行语句。在数据库里面，扫描行数是影响执行代价的因素之一。扫描的行数越少，意味着访问磁盘数据的次数越少，消耗的 cpu 资源越少。

    当然，扫描行数并不是唯一的判断标准，优化器还会结合是否使用临时表、是否排序等因素进行综合判断。

    扫描行数如何计算

    一个索引上不同的值越多，这个索引的区分度就越好。而一个索引上不同的值的个数，称之为“基数”（cardinality）。

  • ?
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
    		•
  • -- 查看当前索引基数
  • mysql> show index from test;
  • +-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
  • | table | non_unique | key_name | seq_in_index | column_name | collation | cardinality | sub_part | packed | null | index_type | comment | index_comment |
  • +-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
  • | test |   0 | primary |   1 | id   | a   |  100256 | null  | null |  | btree  |   |    |
  • | test |   1 | index_a |   1 | a   | a   |  98199 | null  | null | yes | btree  |   |    |
  • +-------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
    		•

    从性能的角度考虑，innodb 使用采样统计，默认会选择 n 个数据页，统计这些页面上的不同值，得到一个平均值，然后乘以这个索引的页面数，就得到了这个索引的基数。因此，上述两个索引显示的基数并不相同。

    而数据表是会持续更新的，索引统计信息也不会固定不变。所以，当变更的数据行数超过 1/m 的时候(innodb_stats_persistent=on时默认10，反之16)，会自动触发重新做一次索引统计。

  • ?
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
    		•
  • mysql> show variables like '%innodb_stats_persistent%';
  • +--------------------------------------+-------------+
  • | variable_name      | value  |
  • +--------------------------------------+-------------+
  • -- 是否自动触发更新统计信息，当被修改的数据超过10%时就会触发统计信息重新统计计算
  • | innodb_stats_auto_recalc    | on   |
  • -- 控制在重新计算统计信息时是否会考虑删除标记的记录
  • | innodb_stats_include_delete_marked | off   |
  • -- 对null值的统计方法，当变量设置为nulls_equal时，所有null值都被视为相同
  • | innodb_stats_method     | nulls_equal |
  • -- 操作元数据时是否触发更新统计信息
  • | innodb_stats_on_metadata    | off   |
  • -- 统计信息是否持久化存储
  • | innodb_stats_persistent    | on   |
  • -- innodb_stats_persistent=on，持久化统计信息采样的抽样页数
  • | innodb_stats_persistent_sample_pages | 20   |
  • -- 不推荐使用，已经被innodb_stats_transient_sample_pages替换
  • | innodb_stats_sample_pages   | 8   |
  • -- 瞬时抽样page数
  • | innodb_stats_transient_sample_pages | 8   |
  • +--------------------------------------+-------------+
    		•
  • ?
  • 1
  • 2
    		•
  • -- 重新统计索引信息
  • mysql> analyze table t;
    		•

    排序对索引选择的影响

  • ?
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64
  • 65
  • 66
  • 67
    		•
  • -- 创建表
  • mysql> create table `t` (
  • `id` int(11) not null,
  • `a` int(11) default null,
  • `b` int(11) default null,
  • primary key (`id`),
  • key `a` (`a`),
  • key `b` (`b`)
  • ) engine=innodb;
  •  
  • -- 定义测试数据存储过程
  • mysql> delimiter ;
  • create procedure idata ()
  • begin
  •  
  • declare i int ;
  • set i = 1 ;
  • while (i <= 100000) do
  •  insert into t
  • values
  •  (i, i, i) ;
  • set i = i + 1 ;
  • end
  • while ;
  • end;
  • delimiter ;
  •  
  • -- 执行存储过程，插入测试数据
  • mysql> call idata ();
  •  
  • -- 查看执行计划，使用了字段a上的索引
  • mysql> explain select * from t where a between 10000 and 20000;
  • +----+-------------+-------+-------+---------------+-----+---------+------+-------+-----------------------+
  • | id | select_type | table | type | possible_keys | key | key_len | ref | rows | extra         |
  • +----+-------------+-------+-------+---------------+-----+---------+------+-------+-----------------------+
  • | 1 | simple   | t   | range | a       | a  | 5    | null | 10000 | using index condition |
  • +----+-------------+-------+-------+---------------+-----+---------+------+-------+-----------------------+
  •  
  • -- 由于需要进行字段b排序，虽然索引b需要扫描更多的行数，但本身是有序的，综合扫描行数和排序，优化器选择了索引b，认为代价更小
  • mysql> explain select * from t where (a between 1 and 1000) and (b between 50000 and 100000) order by b limit 1;
  • +----+-------------+-------+-------+---------------+-----+---------+------+-------+------------------------------------+
  • | id | select_type | table | type | possible_keys | key | key_len | ref | rows | extra               |
  • +----+-------------+-------+-------+---------------+-----+---------+------+-------+------------------------------------+
  • | 1 | simple   | t   | range | a,b      | b  | 5    | null | 50128 | using index condition; using where |
  • +----+-------------+-------+-------+---------------+-----+---------+------+-------+------------------------------------+
  •  
  • -- 方案1：通过force index强制走索引a，纠正优化器错误的选择，不建议使用（不通用，且索引名称更变语句也需要变）
  • mysql> explain select * from t force index(a) where (a between 1 and 1000) and (b between 50000 and 100000) order by b limit 1;
  • +----+-------------+-------+-------+---------------+-----+---------+------+------+----------------------------------------------------+
  • | id | select_type | table | type | possible_keys | key | key_len | ref | rows | extra                       |
  • +----+-------------+-------+-------+---------------+-----+---------+------+------+----------------------------------------------------+
  • | 1 | simple   | t   | range | a       | a  | 5    | null | 999 | using index condition; using where; using filesort |
  • +----+-------------+-------+-------+---------------+-----+---------+------+------+----------------------------------------------------+
  •  
  • -- 方案2：引导 mysql 使用我们期望的索引，按b,a排序，优化器需要考虑a排序的代价
  • mysql> explain select * from t where (a between 1 and 1000) and (b between 50000 and 100000) order by b,a limit 1;
  • +----+-------------+-------+-------+---------------+-----+---------+------+------+----------------------------------------------------+
  • | id | select_type | table | type | possible_keys | key | key_len | ref | rows | extra                       |
  • +----+-------------+-------+-------+---------------+-----+---------+------+------+----------------------------------------------------+
  • | 1 | simple   | t   | range | a,b      | a  | 5    | null | 999 | using index condition; using where; using filesort |
  • +----+-------------+-------+-------+---------------+-----+---------+------+------+----------------------------------------------------+
  •  
  • -- 方案3：有些场景下，我们可以新建一个更合适的索引，来提供给优化器做选择，或删掉误用的索引
  • alter table `t`
  • drop index `a`,
  • drop index `b`,
  • add index `ab` (`a`,`b`) ;
    		•

    索引优化

    索引选择性

    索引选择性 = 基数 / 总行数

  • ?
  • 1
  • 2
    		•
  • -- 表t中字段xxx的索引选择性
  • select count(distinct xxx)/count(id) from t;
    		•

    索引的选择性，指的是不重复的索引值（基数）和表记录数的比值。选择性是索引筛选能力的一个指标，索引的取值范围是 0~1 ，当选择性越大，索引价值也就越大。

    在使用普通索引查询时，会先加载普通索引，通过普通索引查询到实际行的主键，再使用主键通过聚集索引查询相应的行，以此循环查询所有的行。若直接全量搜索聚集索引，则不需要在普通索引和聚集索引中来回切换，相比两种操作的总开销可能扫描全表效率更高。

    实际工作中，还是要看业务情况，如果数据分布不均衡，实际查询条件总是查询数据较少的部分，在索引选择较低的列上加索引，效果可能也很不错。

    覆盖索引

    覆盖索引可以减少树的搜索次数，显著提升查询性能，所以使用覆盖索引是一个常用的性能优化手段

    mysql索引的机制（Mysql索引选择以及优化详解）

  • ?
  • 1
  • 2
  • 3
  • 4
  • 5
    		•
  • -- 只需要查 id 的值，而 id 的值已经在 k 索引树上了，因此可以直接提供查询结果，不需要回表
  • select id from t where k between 3 and 5
  •  
  • -- 增加字段v，每次查询需要返回v，可考虑把k、v做成联合索引
  • select id,v from t where k between 3 and 5
    		•

    最左前缀原则+索引下推

  • ?
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
    		•
  • -- id、name、age三列，name、age上创建联合索引
  •  
  • -- 满足最左前缀原则，name、age均走索引
  • select * from t where name='xxx' and age=12
  •  
  • -- mysql自动优化，调整name、age顺序，，name、age均走索引
  • select * from t where age=12 and name='xxx'
  •  
  • -- name满足最左前缀原则走索引，mysql5.6引入索引下推优化（index condition pushdown)，即索引中先过滤掉不满足age=12的记录再回表
  • select * from t where name like 'xxx%' and age=12
  •  
  • -- 不满足最左前缀原则，均不走索引
  • select * from t where name like '%xxx%' and age=12
  •  
  • -- 满足最左前缀原则，name走索引
  • select * from t where name='xxx'
  •  
  • -- 不满足最左前缀原则，不走索引
  • select * from t where age=12
    		•

    联合索引建立原则：

    前缀索引

  • ?
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
    		•
  • mysql> create table suser(
  • id bigint unsigned primary key,
  • name varchar(64), 
  • email varchar(64),
  • ...
  • )engine=innodb;
  •  
  • -- 以下查询场景
  • mysql> select name from suser where email='xxx';
  •  
  • -- 方案1：全文本索引，回表次数由符合条件的数据量决定
  • mysql> alter table suser add index index1(email);
  •  
  • -- 方案2：前缀索引，回表次数由前缀匹配结果决定
  • mysql> alter table suser add index index2(email(6));
    		•

    前缀索引可以节省空间，但需要注意前缀长度的定义，在节省空间的同时，不能增加太多查询成本，即减少回表验证次数

    如何设置合适的前缀长度？

  • ?
  • 1
  • 2
    		•
  • -- 预设一个可以接受的区分度损失比，选择满足条件中最小的前缀长度
  • select count(distinct left(email,n))/count(distinct email) from suser;
    		•

    如果合适的前缀长度较长？

    比如身份证号，如果满足区分度要求，可能需要12位以上的前缀索引，节约的空间有限，又增加了查询成本，就没有必要使用前缀索引。此时，我们可以考虑使用以下方式：

    倒序存储

  • ?
  • 1
  • 2
    		•
  • -- 查询时字符串反转查询
  • mysql> select field_list from t where id_card = reverse('input_id_card_string');
    		•

    使用hash字段

  • ?
  • 1
  • 2
  • 3
  • 4
  • 5
    		•
  • -- 创建一个整数字段，来保存身份证的校验码，同时在这个字段上创建索引
  • mysql> alter table t add id_card_crc int unsigned, add index(id_card_crc);
  •  
  • -- 查询时使用hash字段走索引查询，再使用原字段精度过滤
  • mysql> select field_list from t where id_card_crc=crc32('input_id_card_string') and id_card='input_id_card_string'
    		•

    以上两种方式的缺点：

    前缀索引对覆盖索引的影响？

  • ?
  • 1
  • 2
    		•
  • -- 使用前缀索引就用不上覆盖索引对查询性能的优化
  • select id,email from suser where email='xxx';
    		•

    唯一索引

    建议使用普通索引，唯一索引无法使用change buffer，内存命中率低

    索引失效

    总结

    到此这篇关于mysql索引选择以及优化的文章就介绍到这了,更多相关mysql索引选择优化内容请搜索开心学习网以前的文章或继续浏览下面的相关文章希望大家以后多多支持开心学习网！

    原文链接：https://www.cnblogs.com/sheung/p/14582450.html

    标签：
    mysql 优化 索引
    上一篇下一篇

    猜您喜欢

    热门推荐

    © 2021 开心学习