详解MySQL索引的底层实现原理

哈希索引： 仅受内存存储引擎支持。
使用哈希函数将索引列值转换为哈希码。
该值所在行的物理地址存储在哈希码对应的槽中。
查询时间复杂度为O(1 )。
受哈希冲突影响，冲突较多时性能会下降。
不支持范围查询和排序。

B树索引： 平衡的多向搜索树。
叶子节点位于同一层，高度为 h。
非叶子节点包含n-1 个键值和n个指针（d≤n≤2 d）。
键值与数据行[key, data]相关联。
多路分支减少了树的高度和磁盘 I/O。
将数据存储在非叶子节点导致容量有限，数据量大时高度会增加。

B+树索引： BTree 优化变体。
非叶子节点只存储键值，所有数据都在叶子节点中。
叶子节点连接为双向链表，有序结构。
键值对应数据行的物理地址。
非叶子节点有n个键值和n+1 个指针（比BTree多）。
磁盘读写成本较低：单个节点有很多键值，树的高度通常为3 -4 级，可存储千万级数据。
查询速度更稳定：范围查询直接遍历叶子节点的链表。

全文索引： 仅受 MyISAM 和 InnoDB 支持。
适用于文本数据的模糊匹配。
处理文本切分以生成单词列表（倒排索引）。
记录包含该单词的数据行的位置。
建设成本高，需要时间和空间。
仅适用于大文本场景，不需要将其用于数字查询或常规短字符串。

B+Tree更适合默认的索引结构。
散列和全文是特定场景的补充。

MYSQL的索引类型：PRIMARY, INDEX,UNIQUE,FULLTEXT,SPAIAL 有什么区别？各适用于什么场合？

上周 MySQL 索引有四种类型。

主要索引。
用于主键。
必须是独一无二的。
不得为空。
例如会员编号。

INDEX 索引。
普通索引。
改进查询。
允许复制。
示例：会员姓名。

唯一索引。
要求是独特的。
可以有多个。
例如，会员卡。

全文索引。
全文搜索。
长文本字段。
例如，会员备注。
搜索单词。
快点找到吧。

我不确定这部分。
使用哪一个？ 这取决于具体情况。
没关系。

MySQL共有多少种常见索引类型mysql一共几个索引

说实话，这个问题问得很详细。
我直接讲MySQL的索引类型。
如果你问“有多少种？”，我会按照你的清单来数。
B+树、散列全文空间 前缀和位图都是可能的。

给我印象最深的是MySQL的标准B+树。
同时调整电子商务系统；我记得产品名称的 SQL 查询运行得像蜗牛一样。
后来，添加了产品名称的B+树索引，响应时间下降了9 0%。
关键是B+树索引比哈希索引更支持范围查询。
我没有太多使用哈希索引。
尝试使用 MyISAM 引擎来存储用户 ID 并运行相同的查询。
它确实很快，但如果你搜索“价格 1 00 和 2 00”，它就很愚蠢，会直接扫描整个表。
这对于快速字典查找特别有用。

全文索引非常有趣。
过去，在构建新闻系统时，用户搜索“特朗普”等关键词，全文索引秒级返回结果。
然而，如果你搜索“特朗普何时这么说？”，全文索引不会按照他说的做。
中文分词需要仔细考虑。
否则，如果您搜索“apple”，则会显示所有结果。
这将是水果摊贩。
这实在令人失望。
InnoDB一直感觉与全文索引不一致，但是现在InnoDB支持全文索引。

我很少遇到空间索引，但是一位从事GIS系统工作的朋友告诉我，使用MyISAM查询点坐标和矩形范围是可以的，但是切换到InnoDB进行多边形查询会降低性能，这取决于具体的业务案例。

前缀是一种妥协。
有一个项目，用户表中的密码字段太长。
索引完整密码会占用大量空间。
这就是我使用前缀的原因；例如，仅对前 2 0 个字符建立索引。
节省存储空间；但“zhangsan”，询问“zhangsang”时存在隐患，必须添加模糊查询过滤器等附加功能。
BTREE和HASH都可以实现前缀索引。
使用哪一种取决于表结构和查询特性。

位图索引在国内用得不多，但在国外用户的报表分析系统中见过。
事件是指某一组用户购买了产品A；检查B和C是否在一个月内购买过。
虽然用户群体不大产品种类很多。
位图索引用于直接按位进行操作，效率非常高。
由于MySQL没有自带位图索引，因此必须使用BITMAP引擎。
这是相当复杂的。

说实话，这六种指标各有千秋，选择真的要看经验。
例如，如果您正在开发财务风险控制系统；数据量不大，但查询逻辑复杂；全文+位图组合即可；如果你做的电子商务需要大量的阅读和较少的写作，那么B+树就是你的最佳选择。
没有任何指标是万能的，必须根据具体的业务情况进行定制。
当我开始这个项目时我意识到了这一点。