MySQL索引
索引为什么能提高 MySQL 查询效率？
索引就像一本书的目录，能让 MySQL 快速定位数据，避免全表扫描。
它一般是 B+ 树结构，查找效率是 O(log n)，比从头到尾扫一遍数据要快得多
除了查得快，索引还能加速排序、分组、连接等操作。
项目中最常见的做法就是通过 create index 为经常用作查询条件的字段建索
能简单说一下索引的分类吗？
- 从功能上分类的话，有主键索引、唯一索引、全文索引；
- 从数据结构上分类的话，有 B+ 树索引、哈希索引；
- 从存储内容上分类的话，有聚簇索引、非聚簇索引。
索引哪些情况下会失效呢？
比如索引列使用了函数、使用了通配符开头的模糊查询、联合索引不满足最左前缀原则，或者使用 or 的时候部分字段无索引等。
索引不适合哪些场景呢？
- 区分度低的列，可以和其他高区分度的列组成联合索引。
- 频繁更新的列，索引会增加更新的成本。
- TEXT、BLOB 等大对象类型的字段，可以使用前缀索引、全文索引替代。
- 当表的数据量很小的时候，不超过 1000 行，全表扫描可能比使用索引更快。
为什么 InnoDB 要使⽤ B+树作为索引？
因为b+树是一种高度平衡的多路查找树，能够降低磁盘的读写次数，同时支持有序遍历和范围查找
哈希表不支持范围查找，二叉树层级太深，b树不太方便范围扫描
B+树的叶⼦节点是单向链表还是双向链表？如果从⼤值向⼩值检索，如何操作？
B+树的叶⼦节点是通过双向链表连接的，这样可以⽅便范围查询和反向遍历。
当执⾏范围查询时，可以从范围的开始点或结束点开始，向前或向后遍历。
在需要对数据进⾏逆序处理时，双向链表⾮常有⽤。
如果需要在 B+树中从⼤值向⼩值进⾏检索，可以先定位到最右侧节点，找到包含最⼤值的叶⼦节点。从根节点开始向右遍历树的⽅式实现。
索引为什么⽤ B+树不⽤普通⼆叉树？
在极端情况下，普通二叉树会退化成为链表，这时候树的高度就等于数据量
此时查找 id=7 就需要 7 次 I/O 操作，相当于全表扫描。⽽ B+ 树作为多叉平衡树，能将数亿级的数据量控制在 3-4层的树⾼，能极⼤减少磁盘的 I/O 次数
为什么不⽤平衡⼆叉树呢？
平衡⼆叉树虽然解决了普通⼆叉树的退化问题，但每个节点最多只有两个⼦节点的问题依然存在
聚族索引和⾮聚族索引有什么区别？
聚簇索引的叶⼦节点存储了完整的数据⾏，数据和索引是在⼀起的
聚簇索引的叶⼦节点只包含了主键值，需要通过回表按照主键去聚簇索引查找其他列的值，唯⼀索引、普通索引等⾮主键索引都是⾮聚簇索引
回表了解吗？
当使⽤⾮聚簇索引进⾏查询时， MySQL 需要先通过⾮聚簇索引找到主键值，然后再根据主键值回到聚簇索引中查找完整数据⾏，这个过程称为回表
覆盖索引了解吗？
覆盖索引指的是：查询所需的字段全部都在索引中，不需要回表，从索引⻚就能直接返回结果
可以将⾼频查询的字段（如 WHERE 条件和 SELECT 列）组合为联合索引，实现覆盖索引。
什么是最左前缀原则？
最左前缀原则指的是： MySQL 使⽤联合索引时，必须从最左边的字段开始匹配，才能命中索引。