|
innodb 存储引擎使用 B + 树的结构。
为什么用b+树，而不是b树，二叉树？
索引是存在磁盘中的，而在磁盘中每次寻址效率都很低（相比于内存）。所以我们需要更“矮胖”的树形结构。b+树每个节点上的指针，也就是度，更多。
那么问题来了：b+树查询方式是二分查找，b树查询方式是中序遍历。这点来看，b+树稳定的差。存储结构和增删改，也不如b树。不过考虑到索引只有在初始化以后很少会变动，b+树的缺点可以不被重视。（此处我自觉认为我说的很有争议）而且查询时查到目标b+树只需要直接向右遍历，这也是一个优点。
为什么用b+树，而不用哈希表做索引？
1，hash表不支持模糊查找
2，不支持范围查找，例如：查找id为100到200之间的user
3，哈希冲突的时候冲突解决，会形成一条链表，这样会增加查询时间。恐怖的是这种最坏情况是没有下限的。
什么是最左前缀原则？
当进行模糊查找时，定位到最左边，然后向右遍历，直到条件不满足。
索引分为聚集索引和辅助索引
聚集索引是主键，如果要查找主键某一范围内的数据，通过叶子节点的上层中间节点就可以得到页的范围，之后直接读取数据页即可。如：SELECT * FROM Profile where id > 1 and id <100
辅助索引，它的叶子节点保存的并不是包含行记录的全部数据，而是相当于主键索引的主键。会多一次跳表的操作。
FIC（fast index creation）原理，与普通index操作有什么不同？
普通：
首先创建一张新的临时表，表结构为通过命令ALTER TABLE新定义的结构。
然后把原表中数据导入到临时表。
接着删除原表。
最后把临时表重命名为原来的表名。
快速：
对于辅助索引的创建，innodb存储引擎会对创建索引的表加上一个S锁（共享锁）。在创建的过程中，不需要重建表，因此速度较之前提高很多，并且数据库的可用性也得到了提高。删除辅助索引操作就更简单了，InnoDB存储引擎只需更新内部视图（），并将辅助索引的空间标记为可用，同时删除MySQL数据库内部视图上对该表的索引定义即可。
由于FIC在索引的创建的过程中对表加上了S锁，因此在创建的过程中只能对该表进行读操作，若有大量的事务需要对目标表进行写操作，那么数据库的服务同样不可用。此外，FIC方式只限定于辅助索引，对于主键的创建和删除同样需要重建一张表。
比FIC更好的方式有哪些？
联合索引，覆盖索引？
离散读？
如何优化离散读？
。。。
|