数据库索引的原理及类型和应用场景

核心思想： 索引就像一本书的目录。没有目录，你要找某个内容只能一页一页翻（全表扫描）。有了目录，你可以先通过目录快速定位到大概的页数，再翻到那一页即可。

技术实现： 索引是一种独立于数据 的、有序的数据结构，它存储了表中某一列或多列的值，以及这些值对应数据行的物理地址（如指针或主键值）。

工作过程（以B+树为例）：

索引类型	数据结构	特点与原理	优点	缺点
B-Tree / B+Tree索引	平衡多路搜索树	最常用、默认类型。数据有序存储，根到叶子路径等长。B+Tree非叶子节点只存键，叶子节点存数据指针并形成链表。	范围查询高效、支持排序、适合高基数数据、支持全键/最左前缀匹配。	不适合模糊查询（如`LIKE '%abc'`），更新代价较高。
哈希索引	哈希表	对索引列计算哈希码，存储哈希码和对应行指针。	等值查询极快（O(1)），适用于精确匹配。	完全不支持范围查询、排序，哈希冲突影响性能，仅适用于Memory引擎等。
全文索引	倒排索引	对文本内容进行分词，建立单词到文档的映射。	支持自然语言搜索、关键词匹配、布尔搜索。	占用空间大，维护代价高，有特定语法。
空间索引（R-Tree）	R树	用于地理空间数据，将空间对象按最小边界矩形组织，支持空间关系计算。	高效支持地理位置查询（如"附近的人"）。	专用于空间数据，使用场景特定。
位图索引	位图	为每个索引列值创建一个位图，位图中每一位代表一行，1表示该行含有此值。	对于低基数列（如性别、状态）非常紧凑高效，适合OLAP复杂查询。	不适合高并发OLTP（锁粒度大），基数高时失去优势。

特殊/衍生类型：

场景描述	推荐的索引类型	理由与说明
主键查询、范围查询、排序、分组	B+Tree（聚集/非聚集）	B+Tree的有序性天然支持这些操作，是通用场景的默认选择。
等值查询（如`user_id = 123`），且无需范围查询	哈希索引（如果存储引擎支持）	哈希索引的O(1)查找速度远超B+Tree。
文本内容搜索（如文章正文、产品描述）	全文索引	B+Tree的`LIKE`在前缀匹配时有效，但全文索引支持语义分词和相关性评分。
地理位置查询（如"查找5公里内的餐厅"）	空间索引（R-Tree）	专门为空间数据和几何关系计算优化。
数据仓库、报表系统、低基数列（性别、省份）	位图索引	压缩率高，多条件AND/OR组合查询时可通过位运算快速完成。
高频查询条件涉及多个列	复合索引	利用最左前缀原则，一个索引覆盖多个查询条件，避免多个单列索引合并。
查询只需要索引中的列	创建覆盖索引	避免回表，极大提升查询性能。例如`SELECT name FROM users WHERE age=25`，建立`(age, name)`的覆盖索引。
列值几乎唯一（如身份证号）	B+Tree索引	高基数时，B+Tree过滤性极好，效率很高。
列值重复度非常高（如状态标志位）	谨慎评估	低基数时，索引过滤性差，可能不如全表扫描。可考虑位图索引（OLAP场景）或与其他列建复合索引。

代价：

最佳实践与原则：

在WHERE、JOIN、ORDER BY、GROUP BY的列上考虑建立索引。
选择区分度高的列：选择性越高（唯一值多），索引效率越好。
最左前缀原则 ：对于复合索引(A, B, C)，它能加速A、(A, B)、(A, B, C)的查询，但无法加速B、C或(B, C)的查询。
避免过度索引：索引不是越多越好，维护索引有成本。监控并删除未使用的索引。
小心使用函数和类型转换 ：WHERE YEAR(create_time)=2023会导致索引失效，应改为范围查询。
利用覆盖索引：尽可能让查询只通过索引完成。
定期分析和维护索引 ：对表进行ANALYZE更新统计信息，帮助优化器做出正确选择；对索引进行重建以消除碎片。

索引是数据库性能优化的核心手段 ，其本质是以空间换时间，通过额外的有序数据结构来加速数据检索。