码迷,mamicode.com
首页 > 数据库 > 详细

13-6_mysql索引_1_Mysql_Learning_Notes_20180719_13-6

时间:2018-11-18 20:05:03      阅读:190      评论:0      收藏:0      [点我收藏+]

标签:返回   缺点   过程   global   esx   tar   serve   inno   learn   

mysql索引_1_Mysql_Learning_Notes

一种在有序数组中查找某一特定元素的搜索算法;
二分查找法的优点是比较少次数,查找速度快,平均性能好;其缺点是要求待查表为有序表,且插入删除困难,因此二分查找方法适用于不经常变动而查找频繁的有序列表.

  • innodb 要求聚集索引列都要求是有序自增列.innnodb 是事务型的存储引擎,其中的行总是会被删除并提交,count(*) 相对要慢一些.

    二叉树,binary tree

  • 二叉树的每个节点至多只有二棵子树(不存在大于2的节点),二叉树的子树有左右有序之分,次序不能颠倒.左子树一定小于根,右子树一定大于根.根节点是子节点的中间节点.

          4
  1               10

平衡树,平衡二叉树,Self balancing binary search tree

  • 改进的二叉查找树.一般的二叉查找树的查询复杂度是跟目标节点到树根的距离(深度)有关,因此当前节点的深度普遍较大时,查询的均摊复杂度会上升.为了更高效的查询就有了平衡树.
  • 平衡二叉树的特点:
    • 它是一棵空树或其左右两个子树的高度差的绝对值不超过1(比如左边高度是6,右的高度只能是5或7),且左右两个子树也是平衡二叉树.
    • 不平衡的树会通过自旋变成平衡树.
    • 平衡树和二叉查找树最大的区别是:前者是平衡的,后者不一定.
    • 数据库里使用平衡二叉树,如果有插入值很大可能会导致其自旋?.
      技术分享图片

      B树,balanced tree(平衡多叉树)

  • 又称B-树\B_树
  • B树,一个节点可以拥有多于2个的子节点的多叉查找树
  • 适合大量数据的读写操作,普遍运用在数据库和文件系统.
  • 一棵m阶(比如m=4阶)的B树满足以下条件.
    • 树中每个节点至多有m个(4个)子节点
    • 除根节点和叶子节点外,其它每个节点至少有m/2个(2个)子节点.
    • 若根节点不是叶子节点,则至少有2个子节点.
    • 所有叶子节点都出现在同一层,叶子节点不包含任何键值信息.
    • 有k个子节点的非叶子节点恰好包含有k-1个键值(索引节点)

      记录中应该用‘节点‘还是‘结节‘,baidu了一下,有师兄解释:一个节点是两线相交,中间的点,另一个结点是最后的点。二叉树好像特别一点,是结点,叶子结点和非叶子节点(但不确定正确性,我就所有都用节点了)

      B+树,与B树不同点在:

  • 有n棵子树对的节点(node)中含有n-1个关键字(key),每个关键字不保存数据,只用来索引,所有数据都保存在叶子节点.
  • 所有的叶子节点中包含了全部关键字的信息,及指向含这些关键字记录的指针,且叶子节点本身依关键字的大小自小而大顺序链接.
  • 所有的非叶子节点可以看成是索引的部分,节点中仅含其子树(根节点)中的最大(或最小)关键字.
  • 在MySQL中,为了方便,直接写成BTREE

    B+树高度相关性

    高度
    1
    2
    3
    4
  • 以三层B+树为列,最查询3次,平均不到3次就可以查询到结果.查询效率高,XFS文件系统也是使用的B+树,所以优于之前的esx4
  • 怎么看innodb的B+TREE层数?,下面以sysbench_testdata.sbtest2为例查看索引层数:
    • 查看相关系统
      ``sql root@localhost [sysbench_testdata]>show create table sbtest2; | sbtest2 | CREATE TABLEsbtest2(idint(11) NOT NULL AUTO_INCREMENT,kint(11) NOT NULL DEFAULT ‘0‘,cchar(120) NOT NULL DEFAULT ‘‘,padchar(60) NOT NULL DEFAULT ‘‘, PRIMARY KEY (id), KEYk_2(k`)
      ) ENGINE=InnoDB AUTO_INCREMENT=67840915 DEFAULT CHARSET=utf8 |
      1 row in set (0.00 sec)

root@localhost [sysbench_testdata]>select count(id) from sbtest2;
+-----------+
| count(id) |
+-----------+
| 67840914 |
+-----------+
1 row in set (56.87 sec)

```

  • 查看information_schema中相关表信息,注意索引的PAGE_NO和:index_id
root@localhost [sysbench_testdata]>SELECT b.name, a.name, index_id, type, a.space, a.PAGE_NO FROM information_schema.INNODB_SYS_INDEXES a, information_schema.INNODB_SYS_TABLES b WHERE a.table_id = b.table_id AND a.space <> 0 and b.name=‘sysbench_testdata/sbtest2‘;
+---------------------------+---------+----------+------+-------+---------+
| name                      | name    | index_id | type | space | PAGE_NO |
+---------------------------+---------+----------+------+-------+---------+
| sysbench_testdata/sbtest2 | PRIMARY |       51 |    3 |    33 |       3 |
| sysbench_testdata/sbtest2 | k_2     |       58 |    0 |    33 |      38 |
+---------------------------+---------+----------+------+-------+---------+
2 rows in set (0.00 sec)

root@localhost [sysbench_testdata]>show global variables like ‘innodb_page_size‘;
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| innodb_page_size | 16384 |
+------------------+-------+
1 row in set (0.00 sec)
  • 到表的文件系统目录中:cd /data/57mysql/mysql3508/data/sysbench_testdata
#hexdump -s 49216 -n 10 ./sbtest2.ibd
000c040 0300 0000 0000 0000 3300               
000c04a

#hexdump -s 622656 -n 10 ./sbtest2.ibd
0098040 0200 0000 0000 0000 3a00               
009804a
  • 注:hexdump中49216和622656是怎么算出来的?这个数分别对应sbtest2表的两个索引,公式是 page_no * innodb_page_size + 64。PRIMARY:316384+64=49216 k_2:3816384+64=622656 ,同时可以观察hexdump结果中的3300和3a00,此数十六进制为33和3a,转换成十进制为:51和58,分别和information_schema中的index_id对应上了.
  • 可以发现 主键索引(PRIMARY)的PAGE_LEVEL 为 0300,表示这棵二级索引树的高度为 4,k_2索引的PAGE_LEVEL 为 0200,表示这棵二级索引树的高度为 3.

哈希索引,Hash Index

  • 建立在哈希表的基础上,它只对使用了索引中的每个值的精确查找有用.
  • 对于每一行,存储引擎计算出了被索引的哈希码(Hash Code),它是一个较小的值,并且有可能和其他行的哈希码不同(对象相等则hashCode一定相等;hashCode相等对象未必相等)
  • 把哈希码保存在索引中,并且保存了一个指向哈希表中的每一行的指针
  • 也叫散列索引.
  • 问题:如果不同对像产生了相同的hashCode(哈希冲突),如在索引表里无法做到一一对应到记录行?
  • 哈希索引优势:合适大量的等值查询,此种情况效率高于B+TREE
  • HASH Index 缺点:
    • 不支持模糊查询和范围查询
    • 不支持排序
    • 不支持联合索引中的最左匹配规则
    • 只能显式应用于HEAP/MEMORY/NDB表
  • 注意:Innodb内部的自适应哈希索引和此处说的不是一回事.自适应哈希索引是没办法被引用和修改的,innodb自适应哈希索引只能用启用或禁用,没办法指定某一个表使用哈希索引.

什么是索引

相当于书目,用于快速检索

  • 优点
    • 提高数据检索效率
    • 提高表间的join效率
    • 利用唯一性索引,保证数据的唯一性.
    • 提交排序和分组效率.
  • 缺点
    • 消耗更多物理存储空间
    • 数据变更时,索引也需要更新,降低更新效率.(更新索引时会导致cpu在sys增高),在5.7以上,可以通过查询得到索引的利用率.

      MySQL 5.7以后怎么查看索引使用情况?
  1. 通过show status like ‘%Handler_read%‘方法查看:整体的
root@localhost [sysbench_testdata]>show status like ‘%Handler_read%‘;
+-----------------------+---------+
| Variable_name         | Value   |
+-----------------------+---------+
| Handler_read_first    | 7       |
| Handler_read_key      | 29      |
| Handler_read_last     | 0       |
| Handler_read_next     | 8446377 |
| Handler_read_prev     | 0       |
| Handler_read_rnd      | 20      |
| Handler_read_rnd_next | 8344612 |
+-----------------------+---------+
7 rows in set (0.00 sec)
  • Handler_read_key这个值代表了一个行将索引值读的次数,很低的值表明增加索引得到的性能改善不高,因为索引并不经常使用。

  • Handler_read_rnd_next 的值高则查询低效,并且应该建立索引补救。这个值是指在数据文件中读下一行的请求数。如果正进行大量的表扫描,Handler_read_rnd_next的值较高,则通常说明表索引不正确或查询没有利用索引

2.查看具体某一个sql的索引使用情况 :

root@localhost [sysbench_testdata]>explain select k from sbtest2 where k=432 limit 2;
+----+-------------+---------+------------+------+---------------+------+---------+-------+--------+----------+-------------+
| id | select_type | table   | partitions | type | possible_keys | key  | key_len | ref   | rows   | filtered | Extra       |
+----+-------------+---------+------------+------+---------------+------+---------+-------+--------+----------+-------------+
|  1 | SIMPLE      | sbtest2 | NULL       | ref  | k_2           | k_2  | 4       | const | 110944 |   100.00 | Using index |
+----+-------------+---------+------------+------+---------------+------+---------+-------+--------+----------+-------------+
1 row in set, 1 warning (0.00 sec)

字段说明:
Type:告诉我们对表所使用的访问方式,主要包含如下集中类型;
◇ all:全表扫描
◇ const:读常量,且最多只会有一条记录匹配,由于是常量,所以实际上只需要读一次;
◇ eq_ref:最多只会有一条匹配结果,一般是通过主键或者唯一键索引来访问;
◇ fulltext:
◇ index:全索引扫描;
◇ index_merge:查询中同时使用两个(或更多)索引,然后对索引结果进行merge 之后再读取表数据;
◇ index_subquery:子查询中的返回结果字段组合是一个索引(或索引组合),但不是一个主键或者唯一索引;
◇ rang:索引范围扫描;
◇ ref:Join 语句中被驱动表索引引用查询;
◇ ref_or_null:与ref 的唯一区别就是在使用索引引用查询之外再增加一个空值的查询;
◇ system:系统表,表中只有一行数据;
◇ unique_subquery:子查询中的返回结果字段组合是主键或者唯一约束;

possible_keys:可能可以利用的索引的名字。这里的索引名字是创建索引时指定的索引昵称;如果索引没有昵称,则默认显示的是索引中第一个列的名字(在本例中,它是“firstname”)。默认索引名字的含义往往不是很明显。  

key:它显示了MySQL实际使用的索引的名字。如果它为空(或NULL),则MySQL不使用索引。  

key_len:索引中被使用部分的长度,以字节计

ref:列出是通过常量(const),还是某个表的某个字段(如果是join)来过滤(通过key)
的;

rows:MySQL所认为的它在找到正确的结果之前必须扫描的记录数。显然,这里最理想的数字就是1。

  1. 通过performance_schema可以查询到.查看sbtest2表索引情况的查询语句:
root@localhost [sysbench_testdata]>select object_type,object_schema,object_name,index_name,count_star,count_read,COUNT_FETCH from performance_schema.table_io_waits_summary_by_index_usage where object_name=‘sbtest2‘;
  • 具体查看过程:
root@localhost [sysbench_testdata]>select object_type,object_schema,object_name,index_name,count_star,count_read,COUNT_FETCH from performance_schema.table_io_waits_summary_by_index_usage where object_name=‘sbtest2‘;
ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
Connection id:    1697669
Current database: sysbench_testdata

+-------------+-------------------+-------------+------------+------------+------------+-------------+
| object_type | object_schema     | object_name | index_name | count_star | count_read | COUNT_FETCH |
+-------------+-------------------+-------------+------------+------------+------------+-------------+
| TABLE       | sysbench_testdata | sbtest2     | PRIMARY    |          0 |          0 |           0 |
| TABLE       | sysbench_testdata | sbtest2     | k_2        |   76287298 |   76287298 |    76287298 |
| TABLE       | sysbench_testdata | sbtest2     | NULL       |    8344631 |    8344631 |     8344631 |
+-------------+-------------------+-------------+------------+------------+------------+-------------+
3 rows in set (0.00 sec)

root@localhost [sysbench_testdata]>select k from sbtest2 where k=432 limit 2;                                                                                                       
+-----+
| k   |
+-----+
| 432 |
| 432 |
+-----+
2 rows in set (0.00 sec)

root@localhost [sysbench_testdata]>select object_type,object_schema,object_name,index_name,count_star,count_read,COUNT_FETCH from performance_schema.table_io_waits_summary_by_index_usage where object_name=‘sbtest2‘;
+-------------+-------------------+-------------+------------+------------+------------+-------------+
| object_type | object_schema     | object_name | index_name | count_star | count_read | COUNT_FETCH |
+-------------+-------------------+-------------+------------+------------+------------+-------------+
| TABLE       | sysbench_testdata | sbtest2     | PRIMARY    |          0 |          0 |           0 |
| TABLE       | sysbench_testdata | sbtest2     | k_2        |   76287300 |   76287300 |    76287300 |
| TABLE       | sysbench_testdata | sbtest2     | NULL       |    8344631 |    8344631 |     8344631 |
+-------------+-------------------+-------------+------------+------------+------------+-------------+
3 rows in set (0.01 sec)

root@localhost [sysbench_testdata]>select k from sbtest2 where id=432 limit 2;                                                                                                               
+-------+
| k     |
+-------+
| 49866 |
+-------+
1 row in set (0.00 sec)

root@localhost [sysbench_testdata]>select object_type,object_schema,object_name,index_name,count_star,count_read,COUNT_FETCH from performance_schema.table_io_waits_summary_by_index_usage where object_name=‘sbtest2‘;
+-------------+-------------------+-------------+------------+------------+------------+-------------+
| object_type | object_schema     | object_name | index_name | count_star | count_read | COUNT_FETCH |
+-------------+-------------------+-------------+------------+------------+------------+-------------+
| TABLE       | sysbench_testdata | sbtest2     | PRIMARY    |          1 |          1 |           1 |
| TABLE       | sysbench_testdata | sbtest2     | k_2        |   76287300 |   76287300 |    76287300 |
| TABLE       | sysbench_testdata | sbtest2     | NULL       |    8344631 |    8344631 |     8344631 |
+-------------+-------------------+-------------+------------+------------+------------+-------------+
3 rows in set (0.00 sec)

root@localhost [sysbench_testdata]>

索引使用建议

  • 哪种情况下应该创建索引
    • 经常检索的列
    • 经常用于表连接的列
    • 经常排序或分组的列
  • 不建议使用索引的情况
    • 基数很低的列
    • 更新频繁但检索不频繁的列
    • BLOB/TEXT等长内容列
    • 很少用于检索的列

聚集索引,clustered index

  • 聚集索引是一种索引,该索引中键值的逻辑顺序决定了表数据行的物理顺序(注:在聚集索引下,数据在物理上按顺序排在数据页上,重复值也排在一起,因而在那些包含范围检查(between、<、<=、>、>=)或使用group by或orderby的查询时,一旦找到具有范围中第一个键值的行,具有后续索引值的行保证物理上毗连在一起而不必进一步搜索,避免了大范围扫描,可以大大提高查询速度)
  • 每张表只能建一个聚集索引,除了TokuDB引擎
  • InnoDB中,聚集索引即表,表即聚集索引(注:mysql一个表只支持一个聚集索引。在innodb里面聚集索引就是整个表,表就是聚集索引,因为innodb的聚集索引后面是整行数据,如果主键由多列组成,btree优先按第一列顺序存储,在聚集索引btree里面每个叶子节点最终存储每行数据,这就是为什么在innodb里面没有任何条件count (*),它会优先选择普通索引来完成扫描,而不是采用主键索引,因为如果扫聚集索引,扫描的数据量更大,产生的IO更大,如果扫描普通辅助索引,那么它的数据结构通常来讲比主键索引小。)
  • MyISAM 没有聚集索引的概念.
  • InnoDB表中主键一定是聚集索引,但聚集索引不一定是主键.
  • 在聚集索引中不要包含经常修改的列,因为码值修改后,数据行必须移动到新的位置。同时新增数据过于离散随机也不合适.
  • INT/BIGINT(单调顺序列)可优先做为聚集索引
  • mysql 聚集索引的选择顺序:如果有主键则选择主键,没有主键则选择第一个not nullable的唯一索引,没有满足要求的唯一键,最后会使用rowid.,但这个rowid为实例级全局id,所以如果聚集索引如果选择rowid,可能会导致性能降低

    主键索引(PRIMARY KEY)

  • 主键由表中的一个或多个字段组成,它的值用于唯一的标识表中的某一条记录;
  • 在表引用中,主键在一个表中引用来自另一个表中的特定记录(外键foreign key应用);
  • 保证数据的完整性
  • 加快数据的操作速度;
  • 主键值不能重复,也不能包含null.
  • 主键选择建议:
    • 对业务透明,无意义,免受业务变化影响.
    • 很少修改和删除
    • 最好是自增的
    • 不要具有动态属性(如随机值)
  • MySQL 5.6.9及以后不管索引定义时,有无显示包含主键,实际都会存储主键值,如:c1为主键,索引z,为c2,c3联合索引,但z会存储c1的值,这一特性加:索引扩展(Index Extensions).
    -查询中是基于主键好,还是唯一索引好?

    唯一索引(UNIQUE KEY)

  • 不允许具有索引值相同的行,从而禁止重复的索引或键值;
  • 严格意义上讲,应该叫唯一约束;
  • 在唯一约束上和主键一样(以MyISAM引擎为代表)
  • 唯一索引允许有空值(null)
  • 一个表只能有一个主键,但可以有多个唯一索引;
  • 唯一索引约束可临时禁用,但主键不行;

    联合索引(Combined Indexes,Multiple-Column Indexes)

  • 多列组成,所以也叫多列索引
  • 字段从左到右排序,如c1,c2,c3的联合索引,首先进行c1排序,c1字段值相同的按c2排序,如果前两列都相同才会按c3排序.
    |c1|c2|c3|
    |-|
    |1|2|2|
    |2|3|2|
    |2|4|2|
    |3|2|0|
    |3|2|2|
  • 适合where条件中的多列组合
  • 有时候,还可以用于避免回表(覆盖索引,需要的数据都在索引覆盖的字段范围内,不需要再去表中取数据,如果使用的覆盖索引,执行计划中的Extra列会显示关键字:using index)
  • MySQL还不支持多列不同排序规则(8.0起支持)
  • 建议:1.where条件中,经常同时出现的列放在联合索引中;2把选择性(过滤性/基数)大的列放在联合索引的最左边(经常出现的列放在最左边).

    覆盖索引(covering indexes)

  • 通过索引数据结构,即可直接返回数据,不需要回表;
  • 执行计划中的Extra列会显示关键字:using index.

13-6_mysql索引_1_Mysql_Learning_Notes_20180719_13-6

标签:返回   缺点   过程   global   esx   tar   serve   inno   learn   

原文地址:https://www.cnblogs.com/2woods/p/9979023.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!