MySQL (二) 创建高性能的索引
索引类型
B-Tree 索引
先来说说 MyISAM 和 InnoDB 索引的简单区别。
MyISAM 使用的前缀压缩技术使得索引更小,InnoDB 则按照原数据格式进行存储。MyISAM 索引通过数据的物理位置引用被索引的行,而 InnoDB 则根据主键引用被索引的行。
B-Tree 索引能够快速方位数据,不需要进行全表扫描,从索引的根节点开始进行搜索。存储引擎通过指向叶子节点的指针向下一层查找。
可以使用 B-Tree 索引查询类型 B-Tree 索引适用于全键值、键值范围或者键前缀查找。
全值匹配
全值匹配指的是和索引中的所有列进行匹配。
匹配最左前缀
只使用索引的第一列。
匹配列前缀
也可以只匹配某一列的值的开头部分。
匹配范围值
查找在 xxx 和 xxx 之间,这里也使用了索引的第一列。
精确匹配某一列并范围匹配另外一列
可以查找 姓名为 Allen 并且是字母 K 开头的人。
只访问索引的查询
查询只需要访问索引,不需要方位数据行。
关于 B-Tree 索引的限制:
如果不是按照最左列开始查找就无法使用索引;
不能跳过索引中的列;
如果查询中有某个列的范围查询,则其右边的所有列都无法使用索引优化查找。
哈希索引
只有精确匹配索引所有列的查询才有效,Memory 引擎显示支持哈希索引。
哈希索引只包含哈希值和行指针不储存字段值。
哈希索引也不支持部分索引列匹配查找。
哈希索引数据并不是按照索引值顺序存储的,也就无法进行排序。
哈希索引只支持等值比较查询。
访问哈希索引的数据非常快。
InnoDB 没有哈希索引,但是有一个特殊功能叫做“自适应哈希索引” 它会在内存中基于 B-Tree 索引之上再创建一个哈希索引。需要触发器来维护哈希值。
在数据量非常庞大的时候,需要增加服务器倒数据的时候,还可以用一致性哈希。
关于一致性哈希和应用看这个链接:
https://www.cnblogs.com/lpfuture/p/5796398.html
https://blog.csdn.net/xiaobluesky/article/details/50429428
全文索引
它查找的是文本中的关键词,适用于 MATCH AGAINST 操作。
索引的优点
索引大大减少了服务器需要扫描的数据量
索引可以帮助服务器避免排序和临时表
索引可以将随机 I/O 变为顺序 I/O。
高性能的索引策略
如果查询中的列不是独立的,MySQL 就不会使用索引。
简化Where 条件的习惯,始终将索引列单独放在比较符号的一侧。
有时候要索引很长的字符列,这会让索引变得大且慢,可以索引开始的部分字符,大大节约索引时间,但是会降低选择性。
创建前缀索引是一种能使索引更小更快的办法,但是MySQL无法使用前缀索引做 ORDER BY 和 GROUP BY。也无法使用前缀索引做覆盖扫描。
多列索引
MySQL 5.0 引入了一种叫“索引合并”的策略,查询能够同时使用两个单列的索引进行扫描,并将结果进行合并。通过 EXPLAIN 和 Extra 列可以看到这点
但是这种一般说明索引建的很糟糕。
选择合适的索引列顺序
索引列顺序意味着索引首先按照最左列进行排序,其次第二列,所以多列索引的列顺序至关重要。
可以根据选择性最高的列放在前面,但是不如避免随机 I/O 和排序那么重要,但是通常是好的选择。
聚簇索引
聚簇索引表示数据行和相邻的键值紧凑地储存在一起。
优点:
可以把相关的数据保存在一起;
数据访问更快;
使用覆盖索引扫描的查询可以直接使用页节点中的主键值。
缺点:
聚簇索引最大限度的提高了 I/O 密集型的应用性能。但是如果数据全部存放在内存中,则访问顺序就没那么重要了;
插入速度严重依赖于插入顺序;
更新聚簇索引列的代价很高;
插入新行可能存在“页分裂”的问题;
聚簇索引可能导致全表扫描变慢;
二级索引可能比想象要更大,二级索引访问需要两次索引查找。
覆盖索引
如果一个索引包含(或者覆盖)所有要查询的字段的值,我们就称之为“覆盖索引”。
索引条目远小于数据行大小。
对 I/O 密集型范围查询会比随机少很多。
对于 InnoDB 避免主键索引的二次查询。