Sql 在添加索引之前，问问自己它是否值得性能损失。

Knuth的智慧之词不适用于索引的创建（或不创建），因为通过添加索引，您不是在直接优化任何东西：您提供了一个DBMS优化人员可用于优化某些查询的索引。事实上，您可以更好地争辩说，决定不索引一个小表是过早的优化，因为这样做会限制DBMS优化人员的选择

不同的数据库管理系统将根据各种因素（包括表大小）选择是否为列编制索引，并且应该考虑这些因素

---

什么是数据库中过早优化的一个例子：在任何基准测试表明标准化数据库实际上存在任何性能问题之前，“性能非标准化”。

作为一般经验法则，最好避免使用较小的索引，因为它们通常不会被使用

---

但有时它们可以提供巨大的提升，正如我所概述的。

您必须了解，根据查询，可以进行两次查找，一次到索引中，以获取指向行的指针，另一次到行本身。如果正在查询的数据位于索引列中，则可能不需要执行额外的步骤

---

即使优化器跟踪索引，数据的二次倾斜速度也可能较慢。我们是否关心，取决于应用程序分析和最终解释计划。

如果表足够小，有聚集索引（通常是主键），并且没有覆盖索引满足查询，SQL Server Optimizer将不使用索引。它将改为表扫描。这是因为对聚集索引的bookup查找非常昂贵。这是有道理的。。。行数据存储在聚集索引的叶节点中，因此SQL使用索引查找或表扫描（粗略地说）在相同的页面上搜索。我的回答更一般——非PK列上的非聚集索引支持b树查找而不是线性扫描。这取决于使用这些表的语句生成的逻辑读取数。如果表被查询得很糟糕，比如说为了参数起见，通过调用一个内联读取表的函数，即使对于一个小表，也可能会导致读取负载。我将查看查询计划，并使用set statistics IO on检查在这个小表上生成了多少磁盘读取。如果不是很多，而且查询的这些部分在查询计划中的成本很低，那么索引中可能就没有什么意义了。底线-这取决于查询表的方式。即使您在一个小表上有大量的读取，也可能不需要索引，因为数据库会缓存它。我认为答案是运行查询解释，然后使用金丝雀版本、功能切换、，等等。创建索引时不太容易出错，因为如果添加唯一的约束，数据库将始终（而不仅仅是“经常”）添加索引。索引会降低写入操作的速度（因为索引也必须更新，并且这些更新也需要在某个时间刷新到磁盘）此外，索引还占用磁盘和内存中的空间，后者会导致更多的交换，从而导致性能下降。

SELECT * FROM MySmallTable <-- No worries... Index won't help

SELECT
    *
FROM
    MyBigTable INNER JOIN MySmallTable ON... <-- Ahh, now I'm glad I have my index.