我最近通过为 SQLite 提供一个很好的索引来将复杂的查询速度提高了一个数量级。像这样的结果让我想知道我是否应该索引很多其他通常用于 JOIN 或 ORDER BY 子句的字段。但我不想过分热心并让它适得其反:我认为一定有一些理由不创建索引,否则默认情况下每个字段都会被索引。
在这种情况下,我使用的是 SQLite,但当然也欢迎与 DBMS 无关的建议。
我最近通过为 SQLite 提供一个很好的索引来将复杂的查询速度提高了一个数量级。像这样的结果让我想知道我是否应该索引很多其他通常用于 JOIN 或 ORDER BY 子句的字段。但我不想过分热心并让它适得其反:我认为一定有一些理由不创建索引,否则默认情况下每个字段都会被索引。
在这种情况下,我使用的是 SQLite,但当然也欢迎与 DBMS 无关的建议。
索引会减慢插入和更新速度(这可能会成为一个非常严重的锁定问题)并占用磁盘空间。差不多就是这样。
索引会占用磁盘空间来存储,并且需要时间来创建和维护。未使用的没有任何好处。如果查询有很多候选索引,则可能会因为让服务器为查询选择“错误”的索引而减慢查询速度。
使用这些因素来决定您是否需要索引。
通常可以创建永远不会使用的索引——例如,一个只有两个可能值的(非空)字段上的索引几乎肯定是没用的。
您需要解释您自己的应用程序的查询,以确保经常执行的查询尽可能使用合理的索引,并且创建的索引不超过所需的索引。
磁盘空间中索引的成本通常是微不足道的。表更改时更新索引的额外写入成本通常适中。额外锁定的成本可能很高。
这取决于表上的读写比率,以及索引实际用于加速查询的频率。