索引对更新列不在索引中的更新语句的影响

我经常看到人们说索引变慢update，delete并且insert。这用作一揽子声明，就好像它是绝对的一样。

在调整数据库以提高性能的同时，我不断遇到这种情况，这种情况似乎在逻辑上对我来说与该规则相矛盾，而且我在任何地方都找不到其他方式可以说或解释的人。

在SQL Server中，并且我相信/假定将使用大多数其他DBMS，您的索引是根据您指定的特定列创建的。插入和删除将始终影响整个行，因此没有办法不会影响索引，但是更新似乎更加独特，它们可以专门影响某些列。

如果我有未包含在任何索引中的列并更新了它们，它们是否会因为我在该表中的其他列上有索引而放慢了速度？

例如，在我的User表中，我有一个或两个索引，主键是Identity / Auto Increment列，外键列上可能还有另一个。
如果我更新没有索引直接在其上的列（例如说他们的电话号码或地址），由于在任何一种情况下我在该表的其他列上都有索引，此更新是否会变慢？我要更新的列不在索引中，因此从逻辑上讲，不应更新索引，不是吗？如果有的话，如果我使用WHERE子句中的索引，我认为它们会加快速度。

您是正确的，更新未编制索引的列不会导致更改索引。在简单的情况下，也不会对桌子产生整体影响。

如果查询可以使用索引查找数据，则可以加快查找速度，但是确切的行为（取决于您的SQL品牌）可能与其他SQL品牌不同。（我主要使用Microsoft SQL Server。）

当然，更新具有大量数据的列可能会导致某些行移动到其他页面等。

对于相对较快的现代系统，从绝大多数系统的性能角度来看，向 OLTP表中添加单个索引可能实际上是不可检测的。就是说，您不应该创建不必要的索引，并且可能不应该为表中的每个列创建单列索引。

您的假设是正确的，因为对于许多查询，有用索引的存在将导致非常明显的速度改进。

尽管您的问题似乎与性能有关，但是在添加索引方面还有其他一些潜在问题，包括但不限于：

1. 将索引添加到表时，创建索引所需的时间可能会导致阻塞。锁的寿命很短，很可能不会造成大问题。

2. 索引更改导致执行计划对于引用该基础表的任何计划均无效。重新编译这些执行计划时，某些查询的性能可能会发生负面变化。

3. 索引修改可能会导致查询返回错误，而先前未返回任何错误。以过滤索引为例，该索引用于返回varchar字段中包含的日期；如果过滤器消除了所有非日期的行，并且该过滤器随后进行了更改，则在尝试转换非日期数据时，依赖于该索引的查询现在可能会失败。

4. 新索引可能会导致执行顺序发生更改，从而可能导致死锁发生，而以前从未发生过。

如果更新操作的目标是固定大小（如整数）的非索引列，那么一般来讲它应该不会慢，但与select语句相比，更新最终也必须写入慢速磁盘。