概念：索引是数据库中一种特殊的数据结构，用于加速对表中数据的查找操作。索引通过存储表中某一列或多列的值及其对应的行位置（如行号或指针），使得数据库可以快速定位数据，而无需扫描整个表。
1、初步了解
数据库在被使用的过程中，最频繁的操作就是查找操作，而一般来说国家、企业的数据库的信息量都非常庞大。如果按照单次遍历的情况下查找数据，大量的服务器访问必然会导致查询速度的减缓甚至服务器的崩溃。因此怎么加快数据的查询变成了一个十分重要的问题。为此就有人引入了索引的概念，其实索引就和目录是类似，记录不同数据的存储信息，虽然这种方式加快了数据的查找效率，但也在其他方面削弱了数据库的 CURD 能力。
索引的分类：索引可以根据数据结构和功能进行分类。按数据结构分为 B-Tree 索引（适用于等值和范围查询）、哈希索引（仅支持等值查询）、全文索引（用于文本搜索）、空间索引（用于地理数据）和 位图索引（适用于低基数列）；按功能分为 主键索引（唯一标识行）、唯一索引（确保列值唯一）、普通索引（无唯一性约束）、复合索引（基于多列）和覆盖索引（包含查询所需的所有列）。
2、磁盘与数据库
在正式了解索引之前我们需要先回顾一下磁盘的概念，具体的内容我前面有写过也可自行查阅，这里不再赘述。
liunx磁盘介绍通过前面的学习，我们可以知道，数据库属于操作系统上的软件层，而数据库本身必然是会和底层的磁盘有联系的。操作系统作为数据库和磁盘的中间层，承担了两者数据交互的功能。下面介绍一下，这三者之间的数据大致数据传输一个流程。
首先我们可以知道的是，当我们通过数据库查找某一条信息时，必须先向OS发起请求，让OS把表从磁盘中加载到物理内存中，然后再从物理内存中查找对应的信息。因为高频次的IO操作会导致查询速度变慢，所以为了加快查询操作，数据库层面，数据库会设置一个Buffer pool缓冲区 ，这个缓冲区的大小还是比较大的，能达到128Mb甚至更多。数据库的各种操作都在上面进行，操作完成后，把对应的数据刷新到操作系统内的缓冲区中，然后当内核中数据量积累到一定程度时，操作系统将数据刷新到磁盘中。同时，为了提高效率，数据库中的数据块是以16kb为单位的(InnoDB存储的默认值)，这与内存和磁盘的分布规则都不太相同。这样划分的目的，主要就是为了减少系统调用的次数，同时OS查询的请求时，一次性地读取磁盘中较多的内容，也就是预加载（多加载一些数据），可以让buffer pool 中存储更多表的信息。这样如果下次查询的过程中，数据在数据库的buffer pool中 ，那就不用再向OS发送请求，可以直接向buffer pool读取，提高查询速率。
下面介绍一下数据库中缓冲区的分块规则和管理方法，这点其实和磁盘中管理数据非常相似。首先我们要管理一个东西，必须先对其进行描述，然后再进行组织管理。这里的具体体现就是用一个page来描述每个内存块，其中包含了指向另外一张page的指针，还有page内的属性，数据等等。然后用数据结构(不一定是链表)管理起来。
3、索引类型
这里仅从常见的索引结构进行介绍，如果没有介绍到的可自行查阅。
3.1、B+Tree 索引(InnoDB)
前面我们知道了数据库管理数据的基础大小为16kb(默认值)，在数据库管理的表文件中，数据内容均是以16kb的page存储的。为了引入下面的索引类型的相关概念，我们可以通过一个插入例子来帮助了解。首先我们先按照下面的格式，对一张表进行插入。
按照如下操作插入对应的一些数据
结果
这里我们先抛出一个问题，为什么我们没有按照特定的顺序插入数据，但是这里数据在这里还是按照键值大小进行排序了呢？ 为了解答这个问题，我们就需要知道为什么表要这样排。这其实就和我们的书本是类似的原理，为什么书本要按照顺序排？当然就是为了方便用目录记载查询。这里也是一样的道理，数据库文件存储的都是表结构，表结构又是由一张张page组成的。假设上述的例子中的几个数据都存储在一张page中，那么他们存储方式就是线性链表存储（储存结构如下图）。为了加快数据的查询，page中会设置对应的目录。通过目录，我们能快速查出表上数据。所以回到开头问题，数据会按照键值大小排序，其实就是为了更好地使用目录。
虽然上面地结构能较好地解决局部数据的查询速率问题，但是如果一张表中含有非常多的page，那么page内部的索引(目录) 对查询速率的优化效果就没有那么好了。所以这里我们就需要再引入一层索引(如下图)。这一层目录我们不存储数据，全部存储索引(下级page链表的第一个page的指针和相关键值)。这样一张page就能够存储至少一千多张page数据，如果依然不能满足存储需求，我们可以再添加一级索引，直到page表能够满足存储需求。这种方式能极大简化查询数据的过程，这种存储方式能指数级减少查询的时间。虽然牺牲了一定空间，不过相较于查询速率的提升，这点空间的浪费不值一提，毕竟数据库的大部分操作也就是查询操作。这种类似于树的索引结构，我们称为B-Tree索引。(注意一下，第二级索引及以上的page节点之间是没有指针相连的，这里画的有点不好)
具体的索引过程就和我们进行快排一样，最高级别的索引中存储着下一级的索引，这个索引会将键值和地址绑定起来，按键值大小，从高到低排序。这里不是将所有的键值依次排，而是抽数排。比如我现在存储了100个键值，那么最上级的索引划分的键值就是 0 ， 25 ，50 ，100. 如果我们要查找的键值在0 - 25 之间，那我们就在通过第一个索引的指针向下找，如果是25 - 50之间，那就通过第二个索引的指针向下找，依次类推，下级索引也是如此(参照下图)。每次向下查找的过程其实都是一次IO操作，因为我们需要通过IO操作把磁盘中对应索引绑定的数据加载到内存当中。
根据上图，我们可以总结一下这种索引方式的优点。由于每级父节点只存储下级节点的索引，所以每个父节点的子节点可以有非常多。这就使得整颗索引树呈现一种又矮又胖的形态，这种形态确保每次查询的途径节点数最少。途径节点树少了，需要查询的请求次数也就少了，IO操作也就变少了。同时由于叶子节点之间是相连的，查询某一个范围内的数据时，不需要再重新遍历树查找，加快了查询的速度。
那么我们为什么使用其他的数据结构，而要用这种b+树结构呢？ 我们可以对比一下其他的数据存储结构。
线性结构(链表)
前面我们提到过，当使用线性结构存储海量数据时，查询速率会非常低下。二叉搜索树
二叉搜索树有一种致命缺陷，那就是会发生线性退化问题，导致可能有很多数据是按线性排列的，所以实际意义不大。AVL/红黑树
AVL/红黑树虽然能很好地解决上述搜索二叉树的问题，但是总体树的形态呈现为高瘦状，也就是说树的高度很大程度上决定了IO次数，这种情况下的查询效率必然不如b+树的矮胖状。而且当查询范围数据时，需要不断重新遍历树。B树
这个数其实就一个问题，也就是叶子节点没有相连，不能范围查找，其他方面和b+树几乎无区别。
3.2 聚簇索引 vs 非聚簇索引
前面介绍了的BTree索引其实属于聚簇索引，这种索引就是上面我们提到的索引方式，通过键值直接找到对应数据，数据在表中的存储结构就是类似于树状的。而非聚簇索引和聚簇索引在存储结构上是一样的，只不过叶子节点上并不存储数据，而是存储主键地址（大致结构如下图）。在InnoDB存储引擎中一般是采用聚簇索引，而MyISAM一般使用的就是非聚簇类的一个存储方式。
除了上面的通过主键来建立索引的方式，其实还有通过别的值来建立索引，也就是通过唯一值建立索引。在InnoDB中，我们一般用通过主键来建立索引，但是我们也会像MyISAM中存储数据一样，存储一张不存任何数据的BTree，叶子节点存储的都是主键。如果我们要通过这个唯一值查询数据，那么就是通过唯一值构建的索引找到主键，再通过主键在由主键构建的索引树中查找对应的数据，这个过程我们一般就称为回表。为什么这里通过唯一键构建的索引树的叶子节点不存储数据呢？一是浪费空间，二是没有必要，因为已经有主键构建的索引树中已经存有数据，直接通过主键查找即可。 除了可以用一个唯一键构建索引，我们还可以通过多个唯一键构建索引，就比如用(name，email)构建索引，那么每个page存储的内容就是一个由这两个键值构成的一个复合键值与指针。这也称为覆盖索引如果我们恰好要寻找的就是email这个值，那么就不需要通过回表这个操作重新查询数据，直接返回对应的email即可。
4、索引操作
以下是数据库中 索引 的常见操作，包括创建、删除、查看、优化等。这些操作适用于大多数关系型数据库（如 MySQL、PostgreSQL、SQL Server 等）。
1. 创建索引
(1) 创建普通索引
CREATE INDEX index_name ON table_name (column_name);
(2) 创建唯一索引
CREATE UNIQUE INDEX index_name ON table_name (column_name);
(3) 创建复合索引
CREATE INDEX index_name ON table_name (column1, column2);
(4) 创建主键索引
ALTER TABLE table_name ADD PRIMARY KEY (column_name);
(5) 创建全文索引（仅支持文本列，一般在MyISAM中才支持）
CREATE FULLTEXT INDEX index_name ON table_name (column_name);
2. 删除索引
(1) 删除普通索引
DROP INDEX index_name ON table_name;
(2) 删除主键索引
ALTER TABLE table_name DROP PRIMARY KEY;
3. 查看索引
(1) 查看表的索引
SHOW INDEX FROM table_name;
(2) 查看索引定义
SHOW CREATE TABLE table_name;
4. 修改索引
(1) 重命名索引
- MySQL 不支持直接重命名索引，需要先删除再创建。
- 其他数据库（如 PostgreSQL）支持：
ALTER INDEX old_index_name RENAME TO new_index_name;
(2) 修改索引类型
- 通常需要先删除再创建。
5. 优化索引
(1) 重建索引
ALTER TABLE table_name ENGINE=InnoDB; -- MySQL
REINDEX TABLE table_name; -- PostgreSQL
(2) 优化表
OPTIMIZE TABLE table_name;
(3) 分析索引使用情况
ANALYZE TABLE table_name;
6. 索引的注意事项
-
选择合适的列：
- 在频繁查询的列上创建索引。
- 避免在低选择性列（如性别）上创建索引。
-
避免过度索引：
- 过多的索引会增加写操作的开销。
-
定期维护索引：
- 使用
OPTIMIZE TABLE或REINDEX命令优化索引。
- 使用
-
监控索引使用情况：
- 使用
EXPLAIN分析查询计划，确保索引被正确使用。
- 使用
7. 示例
(1) 创建索引
CREATE INDEX idx_user_email ON users (email);
(2) 删除索引
DROP INDEX idx_user_email ON users;
(3) 查看索引
SHOW INDEX FROM users;
(4) 优化索引
OPTIMIZE TABLE users;