五、总结一次查询的页面I/O数跟索引高度h呈正相关,主要分为以下几种情况:点查询:聚族索引:h1二级索引:覆盖索引:h2回表查询:h2+h1范围查询:这种情况相对比较复杂,但跟点查询的原理类似,读者可自行分析;全表查询:B+树的叶子结点是通过链表连接起来的,对于全表查询,需要从头到尾将所有的叶子结点访问一遍。索引高度...
假设平均指针大小是8个字节,那么索引树的每个节点可以存储16k/((8+8)*8)≈128。那么:一个拥有3000w数据,且主键是BIGINT类型的表的主键索引树的高度就是(log2^25)/log128 ≈ 25/7 ≈ 3.57 由上面的计算可知:一个千万量级,且存储引擎是MyISAM或者InnoDB的表,其索引树的高度在3~5之间。 参专文章...
那么:一个拥有1600w数据,且主键是BIGINT类型的表的主键索引树的高度就是(log10^7)/log128 ≈ 24/7 ≈ 3.4。 由上面的计算可知:一个千万量级,且存储引擎是MyISAM或者InnoDB的表,其索引树的高度在3~5之间。 说明:这一段对索引树高度的计算,都是基于B+Tree,即InnoDB和MyISAM存储引擎的索引用到的数据结构。
在MySQL 中使用 B+ 树做索引时,B+ 树的高度通常取决于树中节点的数量以及每个节点的度数。在 MySQL 中,B+ 树的度数通常为 128,但是这个值也可以在创建索引时通过设置选项来更改。 对于B+ 树来说,一般来说,树的高度越低越好。低高度意味着树中节点的数量越少,也就意味着树的查询和更新操作所需的时间越少...
此时B+树高度为4,因为有叶子节点的存在。假定数据表一行实际数据为1k大小(一行数据差不多就是那么大吧,估摸着),叶子结点每一页(page)大概可以放16条数据。所以最终能够放进去的数据为4亿*16,大约64亿行。此时,int主键已经超过最大范围。而且每次查询数据走索引的时候需要经过4次io。所以建议将数据约束在三层树结...
全表查询:B+树的叶子结点是通过链表连接起来的,对于全表查询,需要从头到尾将所有的叶子结点访问一遍。 2.3 索引高度理论计算 索引页(非叶子节点)中可以分割为多个扇区,每个扇区再指向某子节点(某页)。 假设非叶子节点扇区数为k个、高度h、叶子结点的行记录数为n,则叶子结点数为k(h-1),总记录数为k(h-1)*...
计算B+树高度的一般公式为: [ \text{高度} = \log_B(N) ] 其中,BBB 是每个节点能存储的键数(或键和指针的组合数),NNN 是数据表中的记录数。由于每个节点的大小固定,BBB 可以根据节点大小和键的大小来计算。 例如,假设每个节点大小为16KB,键大小为8字节,指针大小为6字节,则每个节点能存储的键数为: ...
B+树的高度通常是1-3; 在InnoDB的表空间文件中,约定 page number 为3的代表主键索引的根页,而在根页偏移量为64的地方存放了该B+树的page level。如果page level为1,树高为2,page level为2,则树高为3。索引树高度决定查询的IO次数,当然树高度越大则查询需要的IO次数就越多,查询效率相对来说就越低!
B/B+树是为了磁盘或其它存储设备而设计的一种平衡多路查找树(相对于二叉,B树每个内节点有多个分支),与红黑树相比,在相同的的节点的情况下,一颗B/B+树的高度远远小于红黑树的高度(在下面B/B+树的性能分析中会提到)。B/B+树上操作的时间通常由存取磁盘的时间和CPU计算时间这两部分构成,而CPU的速度非常快,所以...
那么指针数如何计算? 假设主键ID为bigint类型,长度为8字节,而指针大小在InnoDB源码中设置为6字节,这样一共14字节。 那么一个页中能存放多少这样的组合,就代表有多少指针,即 16384 / 14 = 1170。那么可以算出一棵高度为2 的B+树,能存放 1170 * 16 = 18720 条这样的数据记录。