1.索引为什么会加快查询？
数据库文件是存储在磁盘上的，磁盘I/O是数据库操作中最耗时的部分之一。没有索引时，数据库会进行全表扫描（Sequential Scan），这意味着它必须读取表中的每一行数据来查找匹配的行（时间效率为O(n)）。当表的数据量非常大时，就会导致大量的磁盘I/O操作。
有了索引，就可以直接跳到索引指示的数据位置，而不必扫描整张表，从而大大减少了磁盘I/O操作的次数。
MySQL的InnoDB存储引擎默认使用B+树来作为索引的数据结构，而B+树的查询效率非常高，时间复杂度为O(logN)。
索引文件相较于数据库文件，体积小得多，查到索引之后再映射到数据库记录，查询效率就会高很多。
2.索引分类
2.1.按功能划分
①主键索引:表中每行数据唯一标识的索引，强调列值的唯一性和非空性。
②唯一索引:保证数据列中每行数据的唯一性，但允许有空值。
③普通索引:基本的索引类型，用于加速查询。
④全文索引：特定于文本数据的索引，用于提高文本搜索的效率。
2.2.按数据结构划分
①B+树索引：最常见的索引类型，一种将索引值按照一定的算法，存入一个树形的数据结构中（二叉树），每次查询都从树的根节点开始，一次遍历叶子节点，找到对应的值。查询效率是O(logN)。
②Hash索引：基于哈希表的索引，查询效率可以达到O(1)，但是只适合=和in查询，不适合范围查询。
InnoDB并不提供直接创建哈希索引的选项，因为B+树索引能够很好地支持范围查询和等值查询，满足了大多数数据库操作的需要。
不过，InnoDB存储引擎内部使用了一种名为“自适应哈希索引”的技术。
自适应哈希索引并不是由用户显式创建的，而是InnoDB根据数据访问的模式自动建立和管理的。当InnoDB发现某个索引被频繁访问时，会在内存中创建一个哈希索引，以加速对这个索引的访问。
2.3.按存储位置
①聚簇索引：聚簇索引的叶子节点保存了一行记录的所有列信息。也就是说，聚簇索引的叶子节点中，包含了一个完整的记录行。
②非聚簇索引：它的叶子节点只包含一个主键值，通过非聚簇索引查找记录要先找到主键，然后通过主键再到聚簇索引中找到对应的记录行，这个过程被称为回表。
3.创建索引的注意点
①选择合适的列作为索引
经常作为查询条件（WHERE子句）、排序条件（ORDER BY子句）、分组条件（GROUP BY子句）的列是建立索引的好候选。
区分度低的字段，例如性别，不要建索引
频繁更新的字段，不要作为主键或者索引
不建议用无序的值(例如身份证、UUID )作为索引，当主键具有不确定性，会造成叶子节点频繁分裂，出现磁盘存储的碎片化。
②避免过多的索引
每个索引都需要占用额外的磁盘空间。
更新表（INSERT、UPDATE、DELETE操作）时，所有的索引都需要被更新。
维护索引文件需要成本；还会导致页分裂，IO次数增多。
③利用前缀索引和索引列的顺序
对于字符串类型的列，可以考虑使用前缀索引来减少索引大小。
在创建复合索引时，应该根据查询条件将最常用作过滤条件的列放在前面。
4.索引失效场景
1）在索引列上使用函数或表达式：如果在查询中对索引列使用了函数或表达式，那么索引可能无法使用，因为数据库无法预先计算出函数或表达式的结果。
例如：SELECT * FROM table WHERE YEAR(date_column) = 2021。
2）使用不等于（<>）或者NOT操作符：这些操作符通常会使索引失效，因为它们会扫描全表。
3）使用LIKE操作符，但是通配符在最前面：如果LIKE的模式串是以“%”或者“_”开头的，那么索引也无法使用。例如：SELECT * FROM table WHERE column LIKE '%abc'。
4）OR操作符：如果查询条件中使用了OR，并且OR两边的条件分别涉及不同的索引，那么这些索引可能都无法使用。
5）如果MySQL估计使用全表扫描比使用索引更快时（通常是小表或者大部分行都满足WHERE子句），也不会使用索引。
6）联合索引不满足最左前缀原则时，索引会失效。
5.Innodb的数据结构
5.2.Innodb选择B+树的原因(?)
更高效的磁盘IO，因为它减少了磁盘寻道时间和页的加载次数（B树节点大小通常和页大小对齐）。
支持范围查询，与B树相比，B+树的叶子节点通过指针连接成一个链表，这使得范围查询变得非常高效。在B+树上执行范围查询可以简单地从范围的起始点开始，然后沿着链表向后遍历，直到结束点。
查询性能稳定，B+树的所有查找操作都要查到叶子节点，这使得所有的查询操作都有着相同的访问深度，因此查询性能非常稳定。不像某些其他数据结构，如B树，其查询性能因为数据存在所有的节点上导致深度不一致，性能不稳定。
5.2.和B树的原因
①更高的查询效率
B+树的所有值（数据记录或指向数据记录的指针）都存在于叶子节点，并且叶子节点之间通过指针连接，形成一个有序链表。
②更高的空间利用率
在B+树中，非叶子节点不存储数据，只存储键值，这意味着非叶子节点可以拥有更多的键，从而有更多的分叉。
这导致树的高度更低，进一步降低了查询时磁盘I/O的次数，因为每一次从一个节点到另一个节点的跳转都可能涉及到磁盘I/O操作。
③查询效率更稳定
B+树中所有叶子节点深度相同，所有数据查询路径长度相等，保证了每次搜索的性能稳定性。而在B树中，数据可以存储在内部节点，不同的查询可能需要不同深度的搜索。
6.最左前缀匹配
最左前缀原则，也叫最左匹配原则，或者最左前缀匹配原则。
最左匹配原则是指在使用联合索引（即包含多列的索引）时，查询条件从索引的最左列开始并且不跳过中间的列。
如果一个复合索引包含(col1, col2, col3)，那么它可以支持col1、col1,col2和col1, col2, col3的查询优化，但不会优化只有col2或col3的查询。
也就说，在进行查询时，如果没有遵循最左前缀，那么索引可能不会被利用，导致查询效率降低。
7.索引下推优化（？）
不使用索引条件下推优化时存储引擎通过索引检索到数据，然后返回给MySQL Server，MySQL Server进行过滤条件的判断。
当使用索引条件下推优化时，如果存在某些被索引的列的判断条件时，MySQL Server将这一部分判断条件下推给存储引擎，然后由存储引擎通过判断索引是否符合MySQL Server传递的条件，只有当索引符合条件时才会将数据检索出来返回给MySQL服务器。
8.聚簇索引与非聚簇索引
8.1.回表
当使用非聚簇索引查找数据时，数据库会进行两步操作：
1）查找索引：数据库首先会查找非聚簇索引，找到索引键值对应的索引项。这个索引项包含了数据行在磁盘上的位置信息。
2）读取数据：然后，数据库会根据位置信息，去磁盘上读取相应的数据行。
这个过程也被称为“回表”，因为数据库需要先查找索引，然后再根据索引回到数据表中去查找实际的数据。
因此，使用非聚簇索引查找数据通常比使用聚簇索引要慢，因为需要进行两次磁盘访问。当然，如果索引所在的数据页已经被加载到内存中，那么非聚簇索引的查找速度也可以非常快。
8.2.覆盖索引
在辅助索引里面，不管是单列索引还是联合索引，如果select的数据列只用辅助索引中就能够取得，不用去查主键索引，这时候使用的索引就叫做覆盖索引，避免了回表。
8.3.聚簇索引和非聚簇索引的区别
在聚簇索引中，表中的行是按照键值（索引）的顺序存储的。这意味着表中的实际数据行和键值之间存在物理排序的关系。因此，每个表只能有一个聚簇索引。例如，在MySQL的InnoDB存储引擎中，主键就是聚簇索引。
在非聚簇索引中，索引和数据是分开存储的，索引中的键值指向数据的实际存储位置。因此，非聚簇索引也被称为二级索引或辅助索引。表可以有多个非聚簇索引。
