在考虑索引我的sql表之前，应该有多少条记录？
答案 0 :(得分：10)
我会在创建表时创建索引条目。如果您决定在表格增长到100,1000,100000条目后创建索引，则可能需要花费大量时间，并且可能会使您的数据库在您执行时无法使用。
首先考虑表格，创建您认为需要的指数，然后继续。
在某些情况下，您会发现您应该为列编制索引，如果是这样的话，请在发现时修复它。
在搜索字段上创建索引不是预优化，它应该做什么。
答案 1 :(得分：8)
在创建表时，没有充分的理由放弃明显的索引（FK等）。在小型表上使用不必要的索引永远不会明显影响性能，当您的思维进入架构设计时，最好先进行切割。此外，某些索引可用于防止重复，无论表大小如何，都可以使用重复索引。
我想你问题的正确答案是表格中的记录数量与创建索引的时间无关。
答案 2 :(得分：5)
查询时间不可接受时。更好的是，现在创建一些可能有用的索引，并在代表数据填充数据库后对查询运行EXPLAIN或EXPLAIN ANALYZE。如果索引没有帮助，请删除它们。如果存在可以从更多或不同索引中受益的慢查询，请更改索引。
您不会被锁定在最初的索引选择中。试验，并确保衡量效果！
答案 3 :(得分：3)
总的来说，我同意之前的建议。 始终声明表的引用完整性（主键，外键），列约束（非空，检查）。当应用程序将错误数据放入表格时（即使在开发中），您可以避免恶梦。 我会考虑为公共访问列添加索引（在where，＆lt;＆gt;测试中使用的where子句中的列）。 大多数现代RDBMS实现都非常擅长使索引保持最新，而不会影响性能。因此，索引的成本很低。 此外，大多数RDBMS都有查询计划评估程序，它们通过索引或使用某种表扫描查看到数据行的相对成本。因此，性能命中率也是最低的。
答案 4 :(得分：2)
两个
我很认真。如果现在有两行，并且总会有两行，则索引的成本几乎为零。索引比考虑是否应该更快。优化器不会花很长时间才能发现扫描表比使用索引更快。
如果现在有两行，但在不久的将来会有20万行，不编制索引的成本可能会高得惊人。现在是考虑建立索引的合适时机。
话虽如此，请记住在声明主键时会自动获得索引。在大多数情况下，创建没有主键的表会遇到麻烦。因此，您真正需要考虑索引的唯一时间是您希望索引不是主键上的索引。您需要知道此流量以及进行此呼叫的预期量。如果你弄错了，你就会知道，你可以改变决定。
我曾经看过一个在包含20行时没有索引的参考表。由于业务变化，这个表已经增长到大约900行，但应该注意到没有索引的人没有。插入新订单的时间从大约10秒增加到15分钟。
答案 5 :(得分：1)
取决于。
表格中有多少数据？数据插入的频率是多少？许多索引可以减慢插入时间。你总是查询表的所有行吗？在这种情况下，索引可能无济于事。
但这些并不常见。在大多数情况下，您知道您将要查询数据子集。什么领域？是否存在始终加入的公共字段？查看常见或典型查询的查询计划，它通常会显示它在所有时间内花费的时间。
答案 6 :(得分：1)
作为常规问题，我在阅读重表上执行以下：
在写重表（如活动日志）上我避免使用索引，除非它们是绝对必要的。我也倾向于定期将这些数据存档到索引表中。
答案 7 :(得分：1)
如果表上有唯一约束（并且应该至少有一个），那么通常会由唯一索引强制执行。
否则，在查询性能不佳时添加索引，添加索引将显着提高性能。有关如何在表上创建好的索引集的书籍，包括Relational Database Index Design and the Optimizers。它会给你很多想法以及它们为什么好的原因。
另见：
毫无疑问，还有很多其他人。