13-6_mysql索引_1_Mysql_Learning_Notes_20180719

mysql索引_1_Mysql_Learning_Notes

二分查找/折半查找法,binary search

一种在有序数组中查找某一特定元素的搜索算法;

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

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|0|1|468|16KB|

|2|1|1023|>563K|18.8MB|

|3|1024|1447209|>677M|22.1GB|

|4|1448413|1740992427|>814B|25.9TB|

以三层B+树为列,最查询3次,平均不到3次就可以查询到结果.查询效率高,XFS文件系统也是使用的B+树,所以优于之前的esx4
怎么看innodb的B+TREE层数?,下面以sysbench_testdata.sbtest2为例查看索引层数:
- 查看相关系统

root@localhost [sysbench_testdata]>show create table sbtest2;

| sbtest2 | CREATE TABLE `sbtest2` (

  `id` int(11) NOT NULL AUTO_INCREMENT,

  `k` int(11) NOT NULL DEFAULT '0',

  `c` char(120) NOT NULL DEFAULT '',

  `pad` char(60) NOT NULL DEFAULT '',

  PRIMARY KEY (`id`),

  KEY `k_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以后怎么查看索引使用情况?

通过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。

通过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.