mysql hash 索引 vs B-TREE 索引 理解.pdf

TTeerrrryy TTssaanngg mmyyssqqll hhaasshh 索索引引 vvss BB--TTRREEEE 索索引引 理理解解 分类： linux mysql 201 -10-24 21:02 128人阅读 评论 (0) 收藏 举报 hhaasshh 索索引引 当前 memory 引擎, innodb 引擎支持 hash 索引, 索引将存放内存中，(innodb 存放 buffer pool)  innodb 启动 innodb-adaptive-hash-index 参数就能够支持   假设利用  show engine innodb status \G 看到大量类似下图的等待值 (参见 RW-latch 由 brt0sea.c 产生)   建议你使用 skip-innodb_adaptive_hash_index 关闭 innodb hash 索引功能.  索引由 HASH 算法获得， 因此不一定是唯一 HASH 值，需要对索引进行全扫描   如上图描述，数据存放后， HASH 索引表中， 具有数据及 HASH 键专用存放的区间， 而每个 HASH 都与某个数据一一对应 （注，再强调一次不一定唯一哟）   BB--TTRREEEE 索索引引 常用 Innodb 与 MyISAM 引擎都支持 在 Innodb里，有两种形态, 一是primary key形态，其leaf node里存放的是数据，而且不仅存放了索引键的数据，还存放了其 他字段的数据。 二是secondary index，其leaf node和普通的 B-TREE 差不多，只是还存放了指向主键的信息. 而在MyISAM里， 主键和其他的并没有太大区别。 不过和Innodb不太一样的地方是在MyISAM里，leaf node里存放的不是主键的信息，而是指向数据 1 不过和Innodb不太一样的地方是在MyISAM里，leaf node里存放的不是主键的信息，而是指向数据 文件里的对应数据行的信息. 如图描述，如需要获得数据 G6 的信息，那么I/O 顺序为 INDEX PAGE1 - INDEX PAGE2 - G - G6 按照上述顺序，只能够获得 G6 对应的索引信息 【如块信息】而已，真正的数据并非存在该表中， 利用之前获得的 【块信息】可以直接从某个数据块中获得对应的数据信息， 而不需要进行全表扫 描在多个数据块中搜索数据   速速度度比比较较 hash 索引定位快速一步定位数据 B-TREE 索引要从根页子叶才能够找到具体数据，可能存在对 I/O 才能够获得信息    用用于于条条件件判判断断比比较较 hash 索引只能够使用 = IN 等判断方法进行搜索, 对 order by 没有任何加速功能 B-TREE 索引可用于 =, , =, , =, BETWEE, 同样可以用于 like 操作 如 select * from t1 where name like Parti%; (支持) select * from t1 where name like Par%ti%; (支持) select * from t1 where name like %Parti; (不支持)   MySQL 5.6 新参数 --innodb-adaptive-hash-index 能够令 innodb 也具备 hash index 的特性 默认情况下  5.6 启用该功能，但不一定能够获得好处，因此 HASH 索引将会在 INNODB BUFFER 中占用一定的内存空间。 建议自行 BenchMark 一下启用及关闭时的性能再行决定。 更多 上一篇：MySQL SQL 分析 - 参数化查询 vs query cache 功能 下一篇：innodb 命中率评估 查看评论 * 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场 核核心心技技术术类类 目目 全部主题 Java VPN Android iOS ERP IE10 Eclipse CRM JavaScript Ubuntu NFC WAP jQuery 数据库 BI HTML5 Spring Apache Hadoop .NET API HTML SDK IIS Fedora XM