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

说实话，谈数据库索引对我刚入行的时候来说是一件很头疼的事。
各种类型的索引堆叠在一起。
它们看起来都很抽象，但是一旦你使用它们，它就变得流畅了。
我们以B树索引为例。
这东西简直就是灵丹妙药。
记得我们公司有ERP系统的时候，直接在user表的age字段中添加了一个B树索引。
搜索特定年龄段的人的速度非常快。
为什么？因为B树是通过比较节点值的大小来定位数据的，所以顺序读取自然会更快。
但有趣的是，B 树并不适合所有情况。
例如，orders表中有一个关于订单金额的二级索引。
随着数据量的增加，查询效率会降低。
后来查资料发现，当B树索引的数据量特别大时，树的层次数会增加，查询时间复杂度也会增加。

我遇到了哈希索引的陷阱。
那么就需要查看某个用户在上周的所有订单。
结果使用了哈希索引，导致查询崩溃。
为什么？因为哈希索引是直接通过键值定位的，不支持范围查询。
在这种情况下，用户ID肯定不是唯一值。
系统还会对时间戳范围内的所有订单进行哈希处理。
结果出现很多冲突，直接烧毁CPU。
然而，哈希索引有其用武之地。
我们以我们公司OA系统的单点登录为例。
根据用户 token 直接查询数据库比 B 树索引快得多。
毕竟，代币被设计为具有独特的价值。

位图索引是一个不受欢迎但有用的工具。
在开发电信用户的捆绑使用报告系统时，我发现性别和捆绑类型等字段都是整数值，并且很少有唯一值。
一旦使用位图对结果进行索引，查询的效率直接提高了一倍。
为什么？由于位图索引使用位来表示存在或不存在，并且将多个字段组合在一起，例如“性别是男性”和“数据包类型是A”，并且直接按位进行AND运算，因此在几毫秒内即可得出结果。
但说白了，位图索引更新的代价是昂贵的。
想一想，当某个字段的值发生变化时，位图中有多少位需要改变？因此，对于事务流等频繁变化的表使用位图索引是有点问题的。

空间索引 给我印象最深的是帮助仓储物流行业的客户搭建一个系统。
他们的仓库占地数万平方米，系统必须实时检查给定区域内所有货架的状态。
用什么？空间索引。
在这样的场景下，直接使用基于经纬度的B树索引是不可能的。
结果，使用空间索引后，货架搜索速度就像直接看地图一样快，而且定位准确。
但有趣的是，并非所有数据库都原生支持空间索引。
这取决于具体系统是否兼容。
例如，在以前版本的 MySQL 中，空间索引必须使用专门的 R 树结构。

我自己没做过全文索引，但是见过很多案例。
有一个在线文档平台。
用户想要搜索文档中提到的某个专业术语。
全文索引直接对应于关键字，并且还可以找到同义词。
效果非常好。
但说实话，创建全文索引的成本并不低，尤其是对于大型文本库，而且更新索引是一件麻烦的事情。
而且它仅适用于文本字段，例如数字或日期，因此全文索引没有用。

最后我想提一下我遇到的一个错误：不要盲目添加索引。
我记得有一个新同事认为索引越多越好，所以他给表中的每个字段都添加了索引。
结果呢？数据量稍大，查询变慢。
为什么？索引本身也占用空间，管理它会消耗CPU。
因此，索引应该像使用菜刀一样。
该用的时候就用，不该用的时候也不要过度使用。
我的建议是先分析慢查询执行计划，看看索引是否没有被覆盖，然后根据实际需要添加。
例如，如果经常搜索某个字段或者需要查询某个范围，那么添加索引就有意义了。

请说明什么是数据库索引,并列举其优缺点

说实话，使用索引和不使用索引有很大的区别。
我当时在一家电子商务公司的后端工作。
在系统高峰期，用户搜索产品信息就像在等公交车一样。
后来，技术负责人一次操作就添加了索引。
您好，用户报告页面加载速度更快。
具体快了多少？我的印象是查询时间直接从秒级跳到了毫秒级。
这不是吹牛，是真金白银的进步。

有趣的是，索引的原理其实还蛮有趣的。
以B树指标为例。
上次给学员讲课时，从图书馆借书特别有帮助。
如果你想找一本名为《深入理解计算机系统》的书，直接去看目录就可以了，对吧？不是从第一页到最后一页。
这同样适用于数据库索引。
通过创建有序的数据结构，可以快速缩小搜索范围。
我记得有一篇论文提到，设计得当的B树索引的查询效率可以达到对数级别。
与直接扫描桌子相比，光速和蜗牛的区别仅此而已。

但是建立索引并不是没有成本的。
我之前接过一个旧项目。
表格的结构如蜘蛛网般复杂，各种索引如春雨后的蘑菇般添加。
结果呢？一旦数据有一点更新，整个服务器就变成了烫手山芋。
一天晚上，我盯着屏幕，发现输入一条数据慢得离谱。
最后，我发现已经运行了十几次索引更新。
说实话，我当时很困惑。
数据量只有几万，但索引数量却有上百个。
我个人还没有运行过这个的最新版本，但我记得周围有数据
但是话虽如此，索引优化确实很考验你的技能。
我认识一位出色的 DBA。
它在调整索引时，首先会分析业务场景，比如表主要是查询操作还是更新操作，然后相应地设计索引策略。
他对我说了一句非常合乎逻辑的话：“索引就像为数据库盖房子。
没有索引，它就变成棚户区，但有了索引，它就变成高层建筑。
但关键是选择合适的公寓类型。
”这意味着指标并不是越多越好，而是应该根据实际需要而定。

现在很多数据库都有非常智能的内置优化工具，比如PostgreSQL，它可以根据执行计划自动确定最优索引。
但说它完全依赖于自动系统优化可能有点极端。
我仍然认为值得更多地了解基本原理并能够在关键时刻进行手动干预。
我有一个同事，手动重新排序了几个索引，系统性能提高了一倍。
他的老板还给了他奖金。
你说这神奇吗？

数据库索引的优缺点

记得曾经负责维护一个大型电商平台的数据库。
有一天，我的系统突然发生了一些奇怪的事情。
在高峰时段，订单查询变得极其缓慢且像蜗牛一样。
经过一番研究，我发现数据库中的关键查询字段没有建立索引。

看到这一幕，让我深深体会到索引的力量。
解决此问题后，订单查询速度提高了 3 倍，用户体验显着改善。
但与此同时，我意识到索引并不是一切。
例如，如果需要对一张表进行多次增删改查，新添加的索引会使这些操作的效率降低。
再比如，索引保证了数据的唯一性，但同时也增加了数据库所需的存储空间。

等等，还有一件事。
有一天，我突然想到，即使我的数据量增长很快，我也可能需要考虑索引优化和扩展策略。