什么时候应该考虑索引SQL表？ 当查询时间不可接受时，在考虑索引SQL表时，应该有多少记录？< P>。更好的是，现在就创建一些可能有用的索引，并在数据库中填充代表性数据后对查询运行解释或解释分析。如果索引没有帮助，请删除它们。如果存在可以从更多或不同索引中受益的慢速查询，请更改索引

您不会被锁定在索引的初始选择中。进行实验，并确保您衡量性能

我会在创建表时创建索引项。如果您决定在表增加到100、1000、100000个条目之后创建索引，那么这可能会花费大量时间，并且可能会使您的数据库在创建索引时不可用

首先考虑表格，创建您认为需要的索引，然后继续

在某些情况下，您会发现您应该为某个列编制索引，如果是这样，请在发现该列时对其进行修复

---

在搜索字段上创建索引不是预优化，而是应该做的。

在创建表时，没有理由放弃明显的索引（FK等）。在小表上有不必要的索引永远不会明显地影响性能，当您考虑到模式设计时，最好先考虑一下。此外，有些索引用于防止重复，这在不考虑表大小的情况下都很有用

---

我想对你的问题的正确答案是，表中记录的数量应该与何时创建索引无关。

总的来说，我同意前面的建议。 始终声明表（主键、外键）、列约束（非null、检查）的引用完整性。当应用程序将坏数据放入表中时（即使是在开发过程中），可以让您免于噩梦。 我会考虑为常用访问列添加索引（列在您的WHERE子句中，在I=、测试中使用）。 大多数现代RDBMS实现都非常擅长使索引保持最新，而不会影响性能。因此，拥有索引的成本是最低的。 此外，大多数RDBMS都有查询计划计算器，可以通过索引或使用某种表扫描查看数据行的相对成本。因此，性能影响也是最小的

视情况而定

表中有多少数据？多久插入一次数据？很多索引都会减慢插入时间。您总是查询表中的所有行吗？在这种情况下，索引可能不会有多大帮助

---

不过，这些并不是常见的用法。在大多数情况下，您知道您将查询数据的子集。在什么领域？是否存在始终连接在一起的公共字段？查看常见或典型查询的查询计划，它通常会向您显示其所有时间都花在哪里。

作为一项例行工作，我在读取大量表格时执行以下：

• 在创建表时，在公共联接字段（如外键）上创建索引
• 检查查询计划中的视图或存储过程，并在指示表扫描的位置添加索引
• 检查“我的应用程序”查询的查询计划，并在指示表扫描的位置添加索引。（并且经常尝试将它们变成存储过程）

---

在编写繁重的表（如活动日志）时，我避免使用索引，除非它们是绝对必要的。我也倾向于定期将这些数据归档到索引表中。

如果表上有唯一的约束（并且应该至少有一个），则通常由唯一的索引强制执行

否则，在查询性能不好时添加索引，添加索引将明显提高性能。有一些关于如何在表上创建好的索引集的书籍，包括。它会给你很多好的想法和理由

另见：

毫无疑问，还有许多其他的

我是认真的。如果现在有两行，并且总是有两行，索引的成本几乎为零。编制索引比考虑是否应该更快。优化器很快就会发现扫描表比使用索引快

如果现在有两行，但在不久的将来会有200000行，那么不编制索引的成本可能会高得令人望而却步。考虑索引的正确时间是现在。

说到这里，请记住，当您声明主键时，会自动获得索引。在大多数情况下，创建没有主键的表会带来麻烦。因此，您真正需要考虑索引的唯一时间是当您希望索引以外的索引位于主键上时。您需要了解流量，以及拨打此电话的预期音量。如果你弄错了，你就会知道，你可以改变决定

---

我曾经看到一个引用表，它是在包含20行时创建的，没有索引。由于业务的变化，这个表已经增加到大约900行，但是应该注意到缺少索引的人没有注意到。插入新订单的时间从大约10秒增加到15分钟

+1如果你要在一个不是主键的字段上进行查找，那么在创建它时只需对它进行索引。+1在一个小表上存在索引不会伤害任何人！在大表上删除无用索引比在小表上删除无用索引更有意义。