什么是索引?数据库中有哪些索引?各有什么特点?

说实话，谈索引对我刚入行的时候来说是一件很头疼的事。
公司里有一位老人每天都说“指数选择应该像相亲一样”。
他说得很清楚——这取决于和你在一起的人。
我们一一分解，不泛泛而谈。

B树索引是最常见、最实用的东西。
我之前维护过一个电子商务系统。
Users表中有数百万条数据，没有索引的查询速度慢如蜗牛。
改用B+树索引后，查询速度直接提升了一倍。
MySQL InnoDB 默认使用 B+ 树。
这个设计相当聪明，尤其擅长范围查询。
比如勾选“上周下单的用户”，B+树可以将叶子节点向下滑动，效率很高。
但有一个危险需要记住。
B树索引不适合全表扫描。
此时，他们比不使用索引要慢。

我对哈希索引了解甚少，但有一个哈希索引给我留下了深刻的印象。
此前，在Memcached项目中，有朋友坚持开发哈希索引。
结果？查询速度很快，但会因轻微的边界条件而中断。
就好像如果你用身份证号来搜索一个人，可能是准确的，但如果你要搜索“所有9 0后出生的人”，哈希索引就没用了。
所以请记住，这仅适用于同等问题。
适合，且数据不可重复。

我很少使用位图索引，但有一个例子值得一提。
我们创建了一个用户画像系统。
所有性别和年龄列都是重复值。
使用位图索引后，内存占用更小，查询速度更快。
但后来出现了一张表，用户业务类型太分散，位图索引爆了，内存满了。
所以，这个东西取决于列的唯一值密度。
如果太稀疏，请不要使用它。

特殊索引让我了解更多。
空间索引在GIS系统中至关重要。
我以前帮助农业部开发过农业用地规划系统，使用空间索引搜索地块非常快。
就全文索引而言，内容平台现在已经离不开它了。
我们有一个新闻应用程序。
标题和内容全文索引后，搜索准确率直接提高。
但需要注意的是，全文索引对中文分词的要求较高，可能会引发笑话。

说白了，索引就像调味料。
如果加多了，就会有苦味，如果加少了，就会没有味道。
我建议新手从B+树开始，这是最安全的做法。
当确实遇到性能瓶颈时，可以根据数据的特点选择hash、bitmap或者特殊索引。
不要盲目跟风，并且不要添加每个索引，因为这会减慢写入操作。

Mysql面试长跑 --- 索引的类型有哪些

上周，一位客户问我有关 MySQL 索引的问题，这让我摸不着头脑。
幸运的是，我自己核实信息后发现了这一点。
我说这个索引类型很酷...
先说B树索引。
这个东西是最常见的。
你是对的。
上次优化电商项目是在2 02 3 年1 0月，我使用了B树指标。
它确实能够保持数据的有序性，并且很容易做范围查询、排序等，画一棵树就可以了解它的结构。
根节点在最上面，叶子节点之间连接指针，方便遍历。
然而，B 树索引也有缺点。
例如，插入数据时可能需要修改树结构，这可能会影响性能。

我不太喜欢刻度指示器。
2 02 2 年左右，我在上海一家商场做培训时，提到MySQL仅支持MEMORY和HEAP引擎。
它速度快，可以通过哈希函数直接定位，但只能进行等价比较，不能进行排序和范围查询。
当时有同学问我为什么不能用哈希索引。
我说主要是场景限制太多。
你说得对，混乱是最大的缺点。

逻辑分区索引、常规索引、唯一索引、主键索引是我常用的。
比如我去年在杭州做一个项目的时候，用户表使用了主键索引PRIMARY KEY，没有漏掉一个。
唯一索引类似。
我的时间表不需要重复的手机号码，因此我添加了一个唯一约束。
我遇到的空间索引和全文索引较少，但它们确实存在。
空间索引在 GIS 系统中非常常见，例如检查特定区域的仓库。
我记得当我在新闻网站上工作时尝试对全文进行索引。
检索 TEXT 字段的全文非常快。

根据实际使用情况，单列索引和组合索引最为重要。
组合索引顺序千万不能搞错！ 2 02 1 年在北京调试一个慢查询，发现LIKE查询的第一个字符包含%，破坏了内置索引。
后来我改了SQL，把条件前移，索引又可以用了。
这是一个深刻的教训。
写SQL的时候不能盲目加%。

但是根本没有更好的指标，要看情况。
你这个问题问得很系统，总结得很清楚。
然而，指标的选择实际上并不是一个理论上的问题。
应根据实际数据大小、查询频率、表结构来确定。
我还在想这个问题，你觉得呢？

Mysql目前主要的几种索引类型