我们大多数人可能会同意使用数据库索引是好的。太多的索引和性能实际上可能会降低。
通常，应该为哪些字段建立索引？
哪些字段不应该建立索引？
在实现过多索引与不足索引以达到性能提升而不是降级之间的平衡时，使用索引的规则是什么？
Answers:
我认为“索引过多”规则有点误导。
鉴于平均数据库约为98％的读取（或更高），因此需要优化读取。例如，如果存在唯一索引，则INSERT为读取。或在哪里更新。我曾经读过，即使一个写密集型数据库也仍然是85％的读取。
您所要做的就是索引质量差。例子：
cold, cole和cold, cole, colf)请注意，即使在OLTP系统中，索引也比实际数据大几倍是非常典型的。
通常，我将从
然后我看一下：
话虽如此，但我看到了如何解决问题（后来又有100亿行）来调整系统后，才打破了某些系统的这些规则。但是我永远不会考虑不编制索引，除非我能证明为什么这样做。
盖尔·肖（Gail Shaw）简直是最好的系列文章之一，该系列文章中就选择了哪些索引以及为什么选择索引。您可以通过单击此处找到文章
您可以用50种不同的方式回答您提出的问题。实际上，所有这些都归结为您拥有的数据以及如何查询它们。一般规则是，在每个表上都应始终具有聚集索引，以避免堆。聚集索引通常应尽可能小。如果表具有聚簇索引，则非聚簇索引的叶子页上的所有索引记录都将存储各自的聚簇索引的记录值以进行书签查找。如果表是堆，则SQL将为书签查找创建唯一的标识符。我不记得它的大小是8个字节还是16个字节。然后可能会是一个更大的数据类型，然后再说一个INT。想象一下，堆表上有8个非聚集索引。
我想在这里补充一点，不同的数据库需要不同的策略。例如，让我们比较带有InnoDB和PostgreSQL的MySQL。
创新数据库
InnoDB表基本上是主键的b树索引，该索引被扩展为在索引条目中包括行信息。不支持物理顺序扫描，所有扫描均以逻辑顺序进行。这意味着两件事：
Innodb中的顺序扫描会生成大量随机磁盘I / O，并且
无论是否正在使用辅助索引，都必须遍历主键索引。
在此模型中，主键查找比任何其他方法都快。
在这种情况下，索引多页表中的足够字段非常重要。典型的规则是为要过滤的所有内容编制索引。
PostgreSQL的
PostgreSQL使用堆文件，每个文件一个表（某些表可能是多个文件），其中从该堆的可用空间分配元组。支持实物订单扫描。为了使逻辑顺序扫描正常工作，必须添加索引。
PostgreSQL中的主键基本上是唯一索引的子集，其中任何值都不能为NULL。UNIQUE约束是使用隐式索引完成的，并且通过索引中可能的不同操作来支持其他几种索引类型。
这意味着：
假设表相当大，则主键查找需要命中索引文件和表文件。这比MySQL的方法要慢得多，在MySQL的方法中，仅必须遍历索引，并且行包含在索引中。
物理顺序扫描的性能要好得多，从而减少了要处理大量行的随机磁盘I / O。
二级索引扫描的性能优于MySQL，因为仅遍历一个索引即可到达表的物理部分。
在此模型中，索引通常是必需的，但是计划者在使用索引时拥有更大的自由度，而不使用索引的含义通常不那么严重。这些表通常进行了优化（而不是专门研究pkey查找），因此需要的索引更少。
TL; DR
了解您的RDBMS。