树：B+树 - 版本历史

Eijux：/* 关于聚簇索引与非聚簇索引 */

2021-04-27T01:43:17Z

关于聚簇索引与非聚簇索引

←上一版本		2021年4月27日 (二) 09:43的版本
第143行：		第143行：
	: 直观上来说，聚簇索引的叶子节点就是数据节点；而非聚簇索引的叶子节点仍然是索引节点，只不过是指向对应数据块的指针。		: 直观上来说，聚簇索引的叶子节点就是数据节点；而非聚簇索引的叶子节点仍然是索引节点，只不过是指向对应数据块的指针。

			: [[File:索引对比：聚簇索引与非聚簇索引.png\|800px]]

	# 聚集索引：【数据的索引】		# 聚集索引：【数据的索引】

Eijux：/* MySQL 中的应用 */

2021-04-23T09:25:10Z

MySQL 中的应用

←上一版本		2021年4月23日 (五) 17:25的版本
第133行：		第133行：
	: [[File:InnoDB：主索引.png\|600px]]		: [[File:InnoDB：主索引.png\|600px]]
	: [[File:InnoDB：辅助索引.png\|600px]]		: [[File:InnoDB：辅助索引.png\|600px]]


			<pre>
			MySQL 默认存储引擎 InnoDB 只显式支持B-Tree（从技术上来说是B+Tree）索引，对于频繁访问的表，InnoDB会透明建立“自适应hash索引”【InnoDB 的内存结构】，即在B树索引基础上建立hash索引，可以显著提高查找效率，对于客户端是透明的，不可控制的，隐式的。
			</pre>

	=== 关于聚簇索引与非聚簇索引 ===		=== 关于聚簇索引与非聚簇索引 ===

Eijux：/* MySQL 中的应用 */

2021-04-23T09:22:09Z

MySQL 中的应用

@@ 第102行： / 第102行： @@
 == MySQL 中的应用 ==
+MySQL的数据存储在“data”目录下，“data”目录下的文件夹是以数据库为单位的，数据库文件夹下面存放的表数据。【“data/{数据库名}/表文件”】
-=== 关于聚簇索引与非聚簇索引 ===
+* 同一个数据库中，不同的表可以设置不同的存储引擎；
-在《数据库原理》里面，对聚簇索引的解释是： '''聚簇索引的顺序就是数据的物理存储顺序'''； 而对非聚簇索引的解释是：'''索引顺序与数据物理排列无关'''。
+: [[File:MySQL：不同存储引擎的表文件结构.png|600px]]
 === MyISAM ===
@@ 第145行： / 第133行： @@
 : [[File:InnoDB：主索引.png|600px]]
 : [[File:InnoDB：辅助索引.png|600px]]
 === MySQL采用“B+树”原因 ===

Eijux：/* MyISAM */

2021-04-23T09:18:52Z

MyISAM

←上一版本		2021年4月23日 (五) 17:18的版本
第119行：		第119行：

	=== MyISAM ===		=== MyISAM ===
	MyISAM 分别会存在一个“'''索引文件'''”（“.~~MYI”文件）和“~~'''数据文件'''”（“.~~MYD”文件）：【另有“~~*.~~frm”文件，存储表的结构】~~		MyISAM 分别会存在一个“'''索引文件'''”（“.MYI”）和“'''数据文件'''”（“.MYD”）：【另有：“*.frm”存储表的结构】
	: 查询的时候，找到“索引文件”的叶子节点中保存的地址，然后通过地址在“数据文件”找到对应的信息。【“索引文件”的叶子节点指向“数据文件”真正数据记录】		* 查询的时候，找到“索引文件”的叶子节点中保存的地址，然后通过地址在“数据文件”找到对应的信息。【“索引文件”的叶子节点指向“数据文件”真正数据记录】
	: [[File:MyISAM：文件结构.png\|600px]]		: [[File:MyISAM：文件结构.png\|600px]]

Eijux：/* InnoDB */

2021-04-23T09:18:28Z

InnoDB

←上一版本		2021年4月23日 (五) 17:18的版本
第132行：		第132行：

	=== InnoDB ===		=== InnoDB ===
	InnoDB 和 MyISAM ~~的最大区别是它~~'''~~只有一个数据文件~~'''~~：【“数据文件”按照~~ B+树组织，其叶子节点就是数据记录】		InnoDB 和 MyISAM 的最大区别是它只有一个'''数据文件'''（“.ibd”存储“索引和数据”）：【另有：“.frm”存储表的结构】
			*【“数据文件”本身按照 B+树组织，其叶子节点就是数据记录】
			:

Eijux：/* MyISAM */

2021-04-23T09:12:44Z

MyISAM

←上一版本		2021年4月23日 (五) 17:12的版本
第119行：		第119行：

	=== MyISAM ===		=== MyISAM ===
	MyISAM 分别会存在一个“'''索引文件'''~~”和“~~'''数据文件'''”：		MyISAM 分别会存在一个“'''索引文件'''”（“.MYI”文件）和“'''数据文件'''”（“.MYD”文件）：【另有“*.frm”文件，存储表的结构】
	: 查询的时候，找到“索引文件”的叶子节点中保存的地址，然后通过地址在“数据文件”找到对应的信息。【“索引文件”的叶子节点指向“数据文件”真正数据记录】		: 查询的时候，找到“索引文件”的叶子节点中保存的地址，然后通过地址在“数据文件”找到对应的信息。【“索引文件”的叶子节点指向“数据文件”真正数据记录】
			: [[File:MyISAM：文件结构.png\|600px]]

Eijux：/* MySQL采用B+树原因 */

2021-04-23T09:01:58Z

MySQL采用B+树原因

←上一版本		2021年4月23日 (五) 17:01的版本
第143行：		第143行：
	: [[File:InnoDB：辅助索引.png\|600px]]		: [[File:InnoDB：辅助索引.png\|600px]]

	=== ~~MySQL采用B~~+~~树原因~~ ===		=== MySQL采用“B+树”原因 ===
			MySQL 等数据库普遍都采用“B+树”，而不是“B树”。主要有如下原因：【“B+树”相比于“B树”的特点】
			# “B树”和“B+树”最重要的一个区别就是“B+树”只有叶子节点存放数据，其余节点用来索引。而“B树”是每个索引节点都会有 data 域。这就决定了“B+树”更适合用来'''存储外部数据'''。也就是所谓的磁盘数据。
			# 从MySQL InnoDB的角度来看，“B+树”是用来充当索引的，一般来说索引非常大，尤其是关系型数据库这种数据量大的索引能达到亿级别，所以为了'''减少内存的占用'''，索引也会存储在磁盘上。
			# “B+树”的磁盘读写代价更低。“B+树”的内部节点并没有指向关键字具体信息的指针，因此其内部节点相对“B树”更小。如果把所有同一内部节点的关键字存放在同一盘块中，那么盘块所能容纳的关键字数量也越多。一次性读入内存中的需要查找的关键字也就越多。相对来说'''IO读写次数'''也就降低了。
			# “B+树”的查询效率更加稳定。由于非终节点并不是最终指向文件内容的节点，而只是叶子节点中关键字的索引。所以任何关键字的查找必须走一条从根节点到叶子节点的路。所有关键字查询的路径长度相同，导致每一个数据的'''查询效率'''相当。
			# “B+树”所有的 Data 域在叶子节点，一般来说都会进行一个优化，就是将所有的叶子节点用指针串起来。这样遍历叶子节点就能获得全部数据，这样就能进行'''区间访问'''了。

Eijux：/* InnoDB */

2021-04-23T08:57:21Z

InnoDB

←上一版本		2021年4月23日 (五) 16:57的版本
第136行：		第136行：
	InnoDB 也有两种索引：		InnoDB 也有两种索引：
	# 主索引：【聚集索引】，表数据文件本身就是一个索引结构（按 B+树组织），这棵树的叶节点数据保存了完整的数据记录；		# 主索引：【聚集索引】，表数据文件本身就是一个索引结构（按 B+树组织），这棵树的叶节点数据保存了完整的数据记录；
	# 辅助索引：将'''主键'''~~作为数据域，查找时：~~		# 辅助索引：将'''主键'''作为数据域。
	## 通过辅助索引先找到主键，		#* 辅助索引查找时：
	## 然后通过'''主索引'''~~找到对应的主键，从而得到相应的数据信息。~~		#*# 通过辅助索引先找到主键，
			#*# 然后通过'''主索引'''找到对应的主键，从而得到相应的数据信息（“回表”）。
	: [[File:InnoDB：主索引.png\|600px]]		: [[File:InnoDB：主索引.png\|600px]]
	: [[File:InnoDB：辅助索引.png\|600px]]		: [[File:InnoDB：辅助索引.png\|600px]]


	=== MySQL采用B+树原因 ===		=== MySQL采用B+树原因 ===

Eijux：/* 应用 */

2021-04-23T08:55:38Z

应用

@@ 第101行： / 第101行： @@
 * “关键字个数 = 子节点个数”：删除操作后，索引结点（内部节点）中存在的 key，不一定在叶子结点中存在对应的记录。
-== 应用 ==
+== MySQL 中的应用 ==
-=== MyISAM ===
 === InnoDB ===
+InnoDB 也有两种索引：
 === MySQL采用B+树原因 ===

Eijux：/* 特点【相比于 B树】 */

2021-04-23T05:33:35Z

特点【相比于 B树】

←上一版本		2021年4月23日 (五) 13:33的版本
第32行：		第32行：

	=== 特点【相比于 B树】 ===		=== 特点【相比于 B树】 ===
	# ~~层级更少：B~~+~~树中间节点不保存数据，所以每个非叶子节点存储的关键字数更多，树的层级更少（~~'''I/O次数减少'''）所以查询数据更快；【B+树：'''叶子结点以上各层仅作为索引使用'''】		# '''查询数据更快'''：B+树中间节点不保存数据，所以每个非叶子节点存储的关键字数更多，树的'''层级更少'''（'''I/O次数减少'''）所以查询数据更快；【B+树：'''叶子结点以上各层仅作为索引使用'''】
	# ~~查询速度稳定：B~~+~~树所有关键字数据地址都存在叶子节点上，导致每次查找的次数都相同，所以查询速度更稳定~~;【B+树：'''所有关键字都在叶子结点出现'''】		# '''查询速度稳定'''：B+树所有关键字数据地址都存在叶子节点上，导致'''每次查找的次数都相同'''，所以查询速度更稳定;【B+树：'''所有关键字都在叶子结点出现'''】
	#* B树搜索有可能在非叶子结点结束。		#* B树搜索有可能在非叶子结点结束。
	# ~~天然具备排序功能：B~~+树所有的叶子节点数据构成了一个有序链表，在范围查找时更方便，缓存的命中率更高。【B+树：'''叶子节点链表已有序'''】		# '''天然具备排序功能'''：B+树所有的叶子节点数据构成了一个有序链表，在范围查找时更方便，缓存的命中率更高。【B+树：'''叶子节点链表已有序'''】
	# ~~全节点遍历更快：B~~+树遍历整棵树只需要遍历所有的叶子节点即可，而不需要像B树一样需要对每一层进行遍历，这有利于数据库做全表扫描。		# '''全节点遍历更快'''：B+树遍历整棵树只需要遍历所有的叶子节点即可，而不需要像B树一样需要对每一层进行遍历，这有利于数据库做全表扫描。
	#* B树需要通过中序遍历获取。		#* B树需要通过中序遍历获取。

树：B+树 - 版本历史

Eijux：​/* 关于聚簇索引与非聚簇索引 */

Eijux：​/* MySQL 中的应用 */

Eijux：​/* MySQL 中的应用 */

Eijux：​/* MyISAM */

Eijux：​/* InnoDB */

Eijux：​/* MyISAM */

Eijux：​/* MySQL采用B+树原因 */

Eijux：​/* InnoDB */

Eijux：​/* 应用 */

Eijux：​/* 特点【相比于 B树】 */

Eijux：/* 关于聚簇索引与非聚簇索引 */

Eijux：/* MySQL 中的应用 */

Eijux：/* MySQL 中的应用 */

Eijux：/* MyISAM */

Eijux：/* InnoDB */

Eijux：/* MyISAM */

Eijux：/* MySQL采用B+树原因 */

Eijux：/* InnoDB */

Eijux：/* 应用 */

Eijux：/* 特点【相比于 B树】 */