数据库中的索引是什么

老实说，说到数据库索引，我首先需要谈谈我的错误经历。
记得刚进这个行业的时候，我接手了一个老项目。
表和里面的数据并不多，查询执行起来极其缓慢。
老板急得直跺脚。
数据库管理员王一边抽着烟一边说道：“小子，你能试试加个索引吗？”其实我当时就加了这个。
我在主键ID上添加了三个索引。
结果如何？请求很快完成，但录制卡住了。

主要的，粗略来说就是数据库中的“黄页”。
想想看，图书馆里的书很多吧？如果没有目录，你想找《史蒂夫·乔布斯传》，就得从“A”翻到“Z”，对吧？这是没有索引的数据库的状态。
但添加索引类似于目录。
跳到以“J”开头的部分，然后找到“史蒂夫·乔布斯传记”是不是更容易？
最有趣的是索引的具体结构。
我们以 MySQL 为例。
InnoDB引擎默认使用B+树。
这是特别有效的，因为数据存储在叶节点中，而非叶节点存储关键字和指向下一级的指针。
我曾经在测试环境中进行实验。
在百万级别的用户表中，当ID没有建立索引时，查找一条记录就像喝一杯咖啡一样慢；一旦添加索引，几秒钟内即可完成。
这速度的差距可不是一点半点。

但是索引并不是万能的。
之前我负责点餐系统，业务方要索引“性别”字段。
大家想一想，是男人多还是女人多？我立刻就糊涂了：这个索引能给查询带来什么用处？后来我做了一些数学计算，发现整个表都被扫描了女性条目，并且扫描索引并不一定快得多。
这是一个教训：如果字段选择性太低，索引效果可能还不如全表扫描。

维护索引也是一项技术工作。
我看到了每天都会更新数以万计的表格数据的项目。
于是，业务方给所有字段都添加了索引。
每次插入数据时，系统CPU立即增加到1 00%。
这类似于在自行车的每个车轮上安装三个制动器。
看起来很酷，但是很难骑。
后来我们改用延迟索引策略。
在批量更新的时候，我们最初没有维护索引，最后统一重建了。
生产力立即提高。

至于索引类型的选择，应该更具体一些。
我曾参与过金融系统中的项目，在交易流表上使用哈希索引特别有用，因为金额查询是等效查询。
但是，对于用户配置文件表，使用 B 树索引是理想的选择。
毕竟，在年龄、城市等范围内查询 B 树效率更高。
就我个人而言，我没有在分布式环境中运行过这个，但我记得当数据超过一百万级时，B+树的吞吐量比哈希索引高得多。

归根结底，索引就像调味料。
如果你把所有东西都正确地放进去，它就会变得新鲜。
如果放太多，就会很无聊。
了解业务场景很关键：读多写少的场景，索引就是神；在更新频繁的场景下，索引可能会成为一个负担。
我在优化电商系统时发现，在订单表上使用组合索引（产品ID+用户ID）特别有效，但在用户行为表上使用该索引导致写入延迟增加3 0%。
这种权衡无法通过复制手册来理解。

数据库中查询优化的目的是什么？

索引是查询加速器。
ISAM架构是一个古老的解决方案，现在很少使用。
插入列上没有可索引的外键。
需要对列进行排序和分组。
索引对多值列有效，但对小值列无效。
性别列有两个值，索引没有用。
复合索引管理多个排序列。
检查索引的工具，例如 Informix TBCheck。
索引可能无效，使用tbcheck修复。
大量更新后，重建​​索引以加快进程。

少用排序。
应避免对大表进行重复排序。
索引必须与排序列匹配。
不要打乱表格的顺序。
对不同的表进行排序很慢。
简化排序并限制范围。

嵌套查询速度很慢。
顺序访问是一个杀手。
1 000行的三层查询就是1 0亿行。
连接列需要建立索引。
学号列需要建立索引。