人们经常读取索引有一个更新的查询性能的负面影响。 我意识到我们的一个内部表，以确定更精确一点的影响，一个微型基准。
该表是用于生产线8555648表，重达550 MB和8列。 这些列是一个独特的电子邮件领域，另一个是融入数据库datetime格式的日期。
我使用的应用程序是：
更新R_Temp.dbo.Email
设置Date_In = '04 / 09/2008
凡电子邮件（test@gmail.com'）
是空和Date_In 下面是估计的执行计划上没有索引的表：
由于没有索引，SQL Server必须执行一次表扫描，也就是说完全扫描表中找到匹配的行的查询。 以下是本扫描的成本：
I / O成本估计：52.1454
估计的CPU成本：4.70565
估计算成本：56.8511
子树成本估计：56.8511
然后，我创建索引无序（聚集）在电子邮件领域，该指数占用307 MB的磁盘上。
马上就可以看到，使用索引可以提高性能显着，更新的费用从60.6541 0.0165721。 无序指数的另外一个重要特征，RID查找除了索引查找的一部分。 事实上，当指数走过，SQLSERVER然后必须遵循的指针表和读取相应的值。 引述的书，其内容的经典形象，这相当于先找到然后我们访问此页面，然后读课文的章节页码。
这里寻求成本指数（RID查找具有相同的成本）：
估计I / O成本：0.003125
估计的CPU成本：0.0001581
估计算成本：0.0032831
子树成本估计：0.0032831
因此，该指数的使用，降低成本，CPU，磁盘访问请求的执行时间和更广泛。
删除该指数后，我创建了一个有序索引（群集）在电子邮件领域，占地2.6 MB的磁盘空间。 经典形象的有序索引目录：人的姓名和电话号码，按字母顺序列出。 技术上，B-树索引的叶子中含有直接下令，而不是一个指针表中的数据的数据。
它被发现，估计成本比无序指数轻微下降，但索引查找的成本是相同的，并在实践中运行两种类型的索引快速查询。 我们还注意到一个步骤聚集索引的更新，而不是在一个无序的指数的情况下更新表：我们已经看到，无序只是一个索引指向表中的值，并做了更新不像一个有序的索引不会影响。
索引的使用，大大加快了这种类型的更新，时间减少2秒到15我的服务器上的MS的应用。 不过，它应该牢记，性能可迅速恶化时，索引碎片，更新/插入和更新增加的字段上的索引数量。 一如既往，认真规划和详尽的测试阶段才开始生产新的指标是必不可少的。
标签： 索引 ， SQL Server的
