当了解某个的原理时，其实可以不断刨根，但如果这个方向的理解只是为了工作，够用多一点就行，否则拿最常见的数据库来讲，根本无止境，你会好奇从一个表中查出来的数据，是如何存储的，首先可以确定他是存储在文件中的，那么为何拿出来时可以整齐齐地多个列排成一排呢，那是因为记录以多个{Key:columns}形式维护，其中Key则叫做索引，那我们知道多个{Key:columns}是存储在文件中，那是怎么存储在文件中呢，是一个文件（空间）会分成多个固定大小的page，有一部分page存储这些{Key:columns}，并且通过B+tree结构维护这些page，问题来了谁通过B+tree呢，是数据库引擎，还是OS的文件管理，我们知道文件只是逻辑抽象出来的概念，那么实际page可以对应到OS的block，而这些block对应着硬件磁盘的多个连续扇区，而这个文件实际对应哪些block是由inode维护的，inode中有一个文件的meta信息以及数组维护数据写在哪些block，这个数组前面index对应值是直接指向数据，而后面三个index对应值指向的block存的反而是指针指向其他的block（而这些block可能继续存指针，也可能存数据，这种不直接存数据的方法就叫做间接索引）。那么问题回来了，page内维护多个{key:values}，那么page如何与block对应的，每次取表数据，肯定是按page取，而真正的key是存在block内，如何知道哪些block存储哪些key，因为根据key及指向的page才能判断出是否找到了数据或者无需再找哇，疑问就是如何通过关联的block和page完成整个闭环。
疑问就是如何通过关联的block和page完成整个闭环
