Sql 有许多指数的缺点是什么？

最近，我通过给SQLite提供一个好的索引来处理一个复杂的查询，从而将查询速度提高了一个数量级。这样的结果让我想知道是否应该索引许多其他字段，这些字段通常用于连接或ORDERBY子句。但我不想过于热心，让它适得其反：我认为一定有一些原因不创建索引，否则默认情况下每个字段都会被索引

---

在这种情况下，我使用SQLite，但当然也欢迎DBMS不可知的建议。

索引会减慢插入和更新（这可能会成为一个非常严重的锁定问题）并占用磁盘空间。差不多就是这样。

索引占用了存储的磁盘空间，并且需要时间来创建和维护。未使用的没有任何好处。如果一个查询有很多候选索引，那么让服务器为查询选择“错误”索引可能会降低查询速度

使用这些因素来决定是否需要索引

通常可以创建永远不会被使用的索引，例如，只有两个可能值的（非空）字段上的索引几乎肯定是无用的

---

您需要解释您自己的应用程序的查询，以确保频繁执行的查询尽可能使用合理的索引，并且创建的索引不超过执行该查询所需的索引。

索引在磁盘空间中的开销通常很小。当表发生更改时，为更新索引而进行额外写入的成本通常适中。额外锁定的成本可能很高

---

它取决于表上的读写比，以及实际使用索引加速查询的频率。

为了测试您的特定应用程序，您可以将“解释查询计划”放在运行的任何查询之前，并检查结果。它将向您显示它正在使用或未使用索引的位置

通过这种方式，您可以确定在哪里可以使用更多索引，以及它们在哪里不会产生影响

---

我过去常常手工测试那些似乎引起麻烦的查询

这就够了。不要忘记，您也需要适当的索引才能获得良好的插入/更新/删除性能。和所有事情一样，这是一种平衡。插入不会从索引中受益。。。更新和删除需要找到相关的行，因此它们可以从该步骤的索引中获益，但是如果必须使用多个索引，则即使这种益处也可能被否定。正如您所说，这是一种平衡：）在分布极不均匀的情况下，为两个值的字段编制索引（有时）是有用的——数据库通过统计数据了解到了这一点。嗯，根据表和要编制索引的字段，磁盘空间成本并不总是微不足道的。我曾经有过很多这样的例子，索引空间的总和是表空间总和的两倍（或更多）…同意DEM；对于窄表，非聚集索引的大小可以与该表相当。假设一个索引占用了表本身一半的磁盘空间；具有六个索引的表在磁盘上的大小是未索引表的四倍。聚集索引基本上是免费的。不，索引在磁盘空间中的成本并不是“通常微不足道”。索引可能会占用大量空间。