Mysql中的Btree与Hash索引比较
2016-07-07 14:50
411 查看
mysql最常用的索引结构是btree(O(log(n))),但是总有一些情况下我们为了更好的性能希望能使用别的类型的索引。hash就是其中一种选择,例如我们在通过用户名检索用户id的时候,他们总是一对一的关系,用到的操作符只是=而已,假如使用hash作为索引数据结构的话,时间复杂度可以降到O(1)。不幸的是,目前的mysql版本(5.6)中,hash只支持MEMORY和NDB两种引擎,而我们最常用的INNODB和MYISAM都不支持hash类型的索引。
不管怎样,还是要了解一下这两种索引的区别,下面翻译自mysql官网文档中对这两者的解释。
B-Tree 索引特征
B-Tree索引可以被用在像=,>,>=,<,<=和BETWEEN这些比较操作符上。而且还可以用于LIKE操作符,只要它的查询条件是一个不以通配符开头的常量。像下面的语句就可以使用索引:
复制代码代码如下:
SELECT * FROM tbl_name WHERE key_col LIKE 'Patrick%';
SELECT * FROM tbl_name WHERE key_col LIKE 'Pat%_ck%';
下面这两种情况不会使用索引:
复制代码代码如下:
SELECT * FROM tbl_name WHERE key_col LIKE '%Patrick%';
SELECT * FROM tbl_name
4000
WHERE key_col LIKE other_col;
第一条是因为它以通配符开头,第二条是因为没有使用常量。
假如你使用... LIKE '%string%'而且string超过三个字符,MYSQL使用Turbo Boyer-Moore algorithm算法来初始化查询表达式,然后用这个表达式来让查询更迅速。
一个这样的查询col_name IS NULL是可以使用col_name的索引的。
任何一个没有覆盖所有WHERE中AND级别条件的索引是不会被使用的。也就是说,要使用一个索引,这个索引中的第一列需要在每个AND组中出现。
下面的WHERE条件会使用索引:
复制代码代码如下:
... WHERE index_part1=1 AND index_part2=2 AND other_column=3
/* index = 1 OR index = 2 */
... WHERE index=1 OR A=10 AND index=2
/* 优化成 "index_part1='hello'" */
... WHERE index_part1='hello' AND index_part3=5
/* 可以使用 index1 的索引但是不会使用 index2 和 index3 */
... WHERE index1=1 AND index2=2 OR index1=3 AND index3=3;
下面的WHERE条件不会使用索引:
复制代码代码如下:
/* index_part1 没有被使用到 */
... WHERE index_part2=1 AND index_part3=2
/* 索引 index 没有出现在每个 where 子句中 */
... WHERE index=1 OR A=10
/* 没有索引覆盖所有列 */
... WHERE index_part1=1 OR index_part2=10
有时候mysql不会使用索引,即使这个在可用的情况下。例如当mysql预估使用索引会读取大部分的行数据时。(在这种情况下,一次全表扫描可能比使用索引更快,因为它需要更少的检索)。然而,假如语句中使用LIMIT来限定返回的行数,mysql则会使用索引。因为当结果行数较少的情况下使用索引的效率会更高。
Hash 索引特征
Hash类型的索引有一些区别于以上所述的特征:
1.它们只能用于对等比较,例如=和<=>操作符(但是快很多)。它们不能被用于像<这样的范围查询条件。假如系统只需要使用像“键值对”的这样的存储结构,尽量使用hash类型索引。
2.优化器不能用hash索引来为ORDER BY操作符加速。(这类索引不能被用于搜索下一个次序的值)
3.mysql不能判断出两个值之间有多少条数据(这需要使用范围查询操作符来决定使用哪个索引)。假如你将一个MyISAM表转为一个依靠hash索引的MEMORY表,可能会影响一些语句(的性能)。
4.只有完整的键才能被用于搜索一行数据。(假如用B-tree索引,任何一个键的片段都可以用于查找。我觉得可能意味着带通配符LIKE操作符会不起作用)。
后记
顺便记录一下在使用mysql过程中碰到的一些问题:
有时候使用脚本迁移数据时会碰到乱码的问题,即使将表字符集设置成utf8也无济于事,这个时候在执行sql之前加一句set names utf8即可。
////////////
1. hash索引查找数据基本上能一次定位数据,当然有大量碰撞的话性能也会下降。而btree索引就得在节点上挨着查找了,很明显在数据精确查找方面hash索引的效率是要高于btree的;
2. 那么不精确查找呢,也很明显,因为hash算法是基于等值计算的,所以对于“like”等范围查找hash索引无效,不支持;
3. 对于btree支持的联合索引的最优前缀,hash也是无法支持的,联合索引中的字段要么全用要么全不用。
4. hash不支持索引排序,索引值和计算出来的hash值大小并不一定一致。
不管怎样,还是要了解一下这两种索引的区别,下面翻译自mysql官网文档中对这两者的解释。
B-Tree 索引特征
B-Tree索引可以被用在像=,>,>=,<,<=和BETWEEN这些比较操作符上。而且还可以用于LIKE操作符,只要它的查询条件是一个不以通配符开头的常量。像下面的语句就可以使用索引:
复制代码代码如下:
SELECT * FROM tbl_name WHERE key_col LIKE 'Patrick%';
SELECT * FROM tbl_name WHERE key_col LIKE 'Pat%_ck%';
下面这两种情况不会使用索引:
复制代码代码如下:
SELECT * FROM tbl_name WHERE key_col LIKE '%Patrick%';
SELECT * FROM tbl_name
4000
WHERE key_col LIKE other_col;
第一条是因为它以通配符开头,第二条是因为没有使用常量。
假如你使用... LIKE '%string%'而且string超过三个字符,MYSQL使用Turbo Boyer-Moore algorithm算法来初始化查询表达式,然后用这个表达式来让查询更迅速。
一个这样的查询col_name IS NULL是可以使用col_name的索引的。
任何一个没有覆盖所有WHERE中AND级别条件的索引是不会被使用的。也就是说,要使用一个索引,这个索引中的第一列需要在每个AND组中出现。
下面的WHERE条件会使用索引:
复制代码代码如下:
... WHERE index_part1=1 AND index_part2=2 AND other_column=3
/* index = 1 OR index = 2 */
... WHERE index=1 OR A=10 AND index=2
/* 优化成 "index_part1='hello'" */
... WHERE index_part1='hello' AND index_part3=5
/* 可以使用 index1 的索引但是不会使用 index2 和 index3 */
... WHERE index1=1 AND index2=2 OR index1=3 AND index3=3;
下面的WHERE条件不会使用索引:
复制代码代码如下:
/* index_part1 没有被使用到 */
... WHERE index_part2=1 AND index_part3=2
/* 索引 index 没有出现在每个 where 子句中 */
... WHERE index=1 OR A=10
/* 没有索引覆盖所有列 */
... WHERE index_part1=1 OR index_part2=10
有时候mysql不会使用索引,即使这个在可用的情况下。例如当mysql预估使用索引会读取大部分的行数据时。(在这种情况下,一次全表扫描可能比使用索引更快,因为它需要更少的检索)。然而,假如语句中使用LIMIT来限定返回的行数,mysql则会使用索引。因为当结果行数较少的情况下使用索引的效率会更高。
Hash 索引特征
Hash类型的索引有一些区别于以上所述的特征:
1.它们只能用于对等比较,例如=和<=>操作符(但是快很多)。它们不能被用于像<这样的范围查询条件。假如系统只需要使用像“键值对”的这样的存储结构,尽量使用hash类型索引。
2.优化器不能用hash索引来为ORDER BY操作符加速。(这类索引不能被用于搜索下一个次序的值)
3.mysql不能判断出两个值之间有多少条数据(这需要使用范围查询操作符来决定使用哪个索引)。假如你将一个MyISAM表转为一个依靠hash索引的MEMORY表,可能会影响一些语句(的性能)。
4.只有完整的键才能被用于搜索一行数据。(假如用B-tree索引,任何一个键的片段都可以用于查找。我觉得可能意味着带通配符LIKE操作符会不起作用)。
后记
顺便记录一下在使用mysql过程中碰到的一些问题:
有时候使用脚本迁移数据时会碰到乱码的问题,即使将表字符集设置成utf8也无济于事,这个时候在执行sql之前加一句set names utf8即可。
////////////
1. hash索引查找数据基本上能一次定位数据,当然有大量碰撞的话性能也会下降。而btree索引就得在节点上挨着查找了,很明显在数据精确查找方面hash索引的效率是要高于btree的;
2. 那么不精确查找呢,也很明显,因为hash算法是基于等值计算的,所以对于“like”等范围查找hash索引无效,不支持;
3. 对于btree支持的联合索引的最优前缀,hash也是无法支持的,联合索引中的字段要么全用要么全不用。
4. hash不支持索引排序,索引值和计算出来的hash值大小并不一定一致。
相关文章推荐
- Hibernate5配置与使用详解
- mysql explain用法
- 从MySQL Bug#67718浅谈B+树索引的分裂优化
- SQL之mysql常用操作语句(入门级)
- mysql 导入导出
- mysql优化
- MySQL数据库占用的空间、表记录的行数
- MySQL修改主键属性
- mysql随机从数据库查询数据
- MySQL开发中常用的查询语句总结
- mybatis-paginator+mysql 简单案例
- mysql源码rmp包的安装步骤
- MYSQL数据库字段字符集查看修改
- MySQL索引原理及慢查询优化
- 远程登录服务器上的mysql,报错:2003 10061
- Mysql体系结构详解——后台线程(待更新)
- Mysql Innodb小结
- debian下mysql如何远程连接
- mysql数据库root密码忘记的修改
- valgrind 生成mysqld调用图之 select now()跟踪