你什么时候应该考虑索引你的 sql 表？答案

【问题标题】：When should you consider indexing your sql tables?你什么时候应该考虑索引你的 sql 表？
【发布时间】：2009-02-07 02:50:17
【问题描述】：

在我考虑索引我的 sql 表之前应该有多少条记录？

【问题讨论】：

标签： sql indexing

【解决方案1】：

在创建表时没有充分的理由放弃明显的索引（FK 等）。在小型表上使用不必要的索引永远不会显着影响性能，当您考虑架构设计时，最好先考虑一下。此外，一些索引用于防止重复，无论表大小如何，这都是有用的。

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

【讨论】：

+1 小表上存在索引永远不会伤害任何人！在 LARGE 表上删除无用索引比在小型表上更有意义。

【解决方案2】：

作为例行公事，我执行以下操作读取繁重的表格：

在我创建表时在常用连接字段上创建索引，例如外键。
检查视图或存储过程的查询计划并在指示表扫描的地方添加索引。
检查我的应用程序的查询计划，并在指示表扫描的任何地方添加索引。（并且经常尝试将它们变成存储过程）

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

【讨论】：

【解决方案3】：

我会在创建表时创建索引条目。如果您决定在表增长到 100、1000、100000 个条目后创建索引，则可能会花费大量时间，并且可能会在您执行此操作时使您的数据库不可用。

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

在某些情况下，您会发现您应该为一列建立索引，如果是这样，请在发现时修复它。

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

【讨论】：

+1 如果您要查找不是主键的字段，只需在创建时对其进行索引。

【解决方案4】：

当查询时间不可接受时。更好的是，现在创建一些可能有用的索引，并在您的数据库由代表性数据填充后对您的查询运行 EXPLAIN 或 EXPLAIN ANALYZE。如果索引没有帮助，请删除它们。如果存在可以从更多或不同索引中受益的慢查询，请更改索引。

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

【讨论】：

【解决方案5】：

两个。

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

如果现在有两行，但在不久的将来会有 200,000 行，那么不编制索引的成本可能会变得高得令人望而却步。现在是考虑编制索引的最佳时机。

话虽如此，请记住在声明主键时会自动获取索引。在大多数情况下，创建没有主键的表是自找麻烦。所以你真正需要考虑索引的唯一时间是当你想要一个索引而不是主键上的索引时。您需要了解流量以及拨打此电话的预期音量。如果你弄错了，你会知道的，你可以撤销决定。

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

【讨论】：

【解决方案6】：

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

【讨论】：

【解决方案7】：

视情况而定。

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

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

【讨论】：

【解决方案8】：

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

否则，当查询性能不佳时添加索引，添加索引将明显提高性能。有一些关于如何在表上创建好的索引集的书籍，包括Relational Database Index Design and the Optimizers。它会给你很多想法以及它们为什么好的原因。

另见：

毫无疑问，还有很多其他人。

【讨论】：