MySQL InnoDB&MyISAM 反对Hash么
咱们在应用MySQL的时候,对于索引的数据类型,应用的最多的就是HASH和BTREE. 很多开发人员很有教训的会在创立某些字段的索引的时候通知MySQL的存储引擎:应用HASH !. 我一段时间也是这样胸有成竹的依照这个实践抉择索引类型的: 如果是准确的equals比拟查问,那么就应用HASH,如果应用范畴查问和大小比拟查问那么最好应用BTREE.
因为以前的开发经验就是性能开发为主,对具体的细节不是很在意,个别MySQL也能满足需要,所以我天真的认为既然建表语句能够指定HASH而且没有报正告和谬误,那么这个索引的底层数据结构必定是HASH,而后我就释怀的应用equals准确查问数据了.直到有一天我看到MySQL的官网文档,才对这个产生粗浅的反思.
原文如下:
Most MySQL indexes (PRIMARY KEY, UNIQUE, INDEX, and FULLTEXT) are stored in B-trees. Exceptions: Indexes on spatial data types use R-trees; MEMORY tables also support hash indexes; InnoDB uses inverted lists for FULLTEXT indexes.
什么? 绝大多少MySQL index是BTREE?除了空间地位数据应用了RTREE以及MEMORY TABLE以及应用倒排列表的FULLTEXT indexes?
InnoDB 官网解读
而后我马上查看了InnoDB的文档:
发现InnoDB其实是不反对HASH索引的,然而它能够应用称为Adaptive Hash的技术来在表象上反对HASH. 这也就是我为什么以前应用InnoDB引擎并指定index类型为HASH的来建表并执行SQL的时候,性能仍然看起来失常的实质起因.
MyISAM 官网解读
我持续查看了MyISAM的文档:
那么很遗憾,MyISAM也是不反对Hash的.而且MyISAM也不反对相似InnoDB的Adaptive Hash的技术来在表象上反对HASH.
所以咱们得出结论:
- MyISAM和InnoDB 不反对HASH
- InnoDB能够应用
Adaptive Hash来间接反对HASH - MEMOEY能力同时反对HASH和BTREE
咱们在建表时给某些字段增加hash索引,或者前期为某表增加hash索引时,如果他们的存储引擎为InnoDB或MyISAM,则sql脚本自身是不会报错的,然而咱们会发现,该hash索引字段的index_type依然为BTREE.这其实是MySQL为了关照应用习惯而做到一些非凡解决,其实底层会疏忽你指定索引为HASH的逻辑,仍然应用BTREE
理论验证
本次我应用MySQL8作为测试环境,通过理论的代码操作做理论的论证.
InnDB验证
CREATE TABLE index_type_test ( `id` INT NOT NULL AUTO_INCREMENT, `name` VARCHAR(32) NULL, PRIMARY KEY (`id`), UNIQUE INDEX `name_UNIQUE` using hash(name)) ENGINE = InnoDB;而后咱们查问这个表的索引类型:
mysql> show index from index_type_test;
所以理论测试表明InnoDB会疏忽你指定的HASH类型,仍然应用BTREE
MyISAM验证
CREATE TABLE index_type_test ( `id` INT NOT NULL AUTO_INCREMENT, `name` VARCHAR(32) NULL, PRIMARY KEY (`id`), UNIQUE INDEX `name_UNIQUE` using hash(name)) ENGINE = MyISAM;而后咱们查问这个表的索引类型:
所以理论测试表明MyISAM会疏忽你指定的HASH类型,仍然应用BTREE.
本文原创链接:
- MySQL InnoDB&MyISAM 反对Hash么
参考链接:
- InnoDB和MyISAM是否反对hash索引