网站开发 进度表,wordpress 切换中文,黑色网站后台,wordpress插件xiazai为什么MySQL的MyISAM和InnoDB存储引擎索引底层选择B树#xff0c;而不是B树#xff1f;哈希索引#xff1a;具体项目实践步骤#xff1a; 为什么MySQL的MyISAM和InnoDB存储引擎索引底层选择B树#xff0c;而不是B树#xff1f; 对于B树#xff1a; 索引数据内容分散在不… 为什么MySQL的MyISAM和InnoDB存储引擎索引底层选择B树而不是B树哈希索引具体项目实践步骤 为什么MySQL的MyISAM和InnoDB存储引擎索引底层选择B树而不是B树 对于B树 索引数据内容分散在不同的节点上离根节点近搜索就快离根节点远搜索就慢。 花费的磁盘IO次数不平均每一行数据搜索花费的时间也不平均。 每一个非叶子节点上不仅仅要存储索引key还要存储索引值所在那一行的data数据。一个节点所能存放的索引key值的个数比只存储索引key值的个数要少很多。 B树不方便做范围搜索整表遍历也不方便。 对于B树 每一个非叶子节点只存放key不存放data好处就是一个节点可以存放更多的key值在理论上来说层数会更低搜索效率会更高。 叶子节点上存储了所有的索引值和数据data搜索每一个索引对应的值data都需要到达叶子节点上这样每一行数据搜索花费的时间非常平均。 叶子节点被串在一个链表当中形成了一个有序链表如果要进行索引树的搜索或者整表搜索或者范围搜索可直接遍历有序链表效率大大提升。
哈希索引
基于哈希表数据结构实现时间复杂度是O(1)。对于memory内存的存储引擎操作比较适合不适合磁盘IO操作。哈希索引没办法处理磁盘上的数据加载到内存上构建高效的搜索数据结构因为它没有办法减少磁盘IO次数。 由于哈希表中的元素没有顺序哈希索引只适合等值搜索比较不适合范围搜索前缀搜索ORDER BY排序等。
在InnoDB存储引擎下对于频繁的使用二级索引会被自动优化–自适应哈希索引即它会根据这个二级索引在内存上根据二级索引树B树上的二级索引值在内存上构建一个哈希索引以加快搜索。
自适应哈希索引本身的数据维护也是要耗费性能的并不是说自适应哈希索引在任何情况下都会提升二级索引的查询性能。应该按照参数指标来具体分析是否打开或关闭自适应哈希索引。
show engine innodb status\G;主要可以看到 1. 出现RW-latch等待的线程数量自适应哈希索引默认分配了8个分区同一个分区等待的线程数量过多 2. 0.00 hash searches/s, 0.00 non-hash searches/s 可以看到自适应哈希索引搜索的使用频率和二级索引树搜索的频率。当自适应哈希索引搜索的使用频率低时要考虑关闭自适应哈希索引。
下面是官方文档介绍 In MySQL 5.7, the adaptive hash index search system is partitioned. Each index is bound to a specific partition, and each partition is protected by a separate latch. Partitioning is controlled by the innodb_adaptive_hash_index_parts configuration option. In earlier releases, the adaptive hash index search system was protected by a single latch which could become a point of contention under heavy workloads. The innodb_adaptive_hash_index_parts option is set to 8 by default. The maximum setting is 512. The hash index is always built based on an existing B-tree index on the table. InnoDB can build a hash index on a prefix of any length of the key defined for the B-tree, depending on the pattern of searches that InnoDB observes for the B-tree index. A hash index can be partial, covering only those pages of the index that are often accessed. You can monitor the use of the adaptive hash index and the contention for its use in the SEMAPHORES section of the output of the SHOW ENGINE INNODB STATUS command. If you see many threads waiting on an RW-latch created in btr0sea.c, then it might be useful to disable adaptive hash indexing.
具体项目实践步骤
1.通过慢查询日志 可设置合理的业务可以接收的慢查询时间 2.压测执行各种业务 3.查看慢查询日志找出所有的执行耗时的sql语句 4.用explain分析这些耗时的sql 5.举例子解决问题
可通过
show variables like profiling;查看profiling的运行状态
set profiling on;show profiles 查看sql语句具体详细的耗费时间。
