选择索引：查询VS 修改性能

I/O是决定查询性能的主要因素。数据库设计者的挑战是构建物理数据模型来提供高效的数据访问。在数据库表中创建索引允许SQL Server降低I/O数来访问数据。在逻辑和物理模型阶段定义有用的索引是关键。SQL Server优化器严重依赖于索引键值的分布和索引密度来决定查询使用哪一个索引。SQL Server优化器能使用查询中的多个索引（通过索引交叉）降低I/O的数量来检索信息。若缺少索引，优化器执行表扫描，从IO角度来讲，它花费的代价更高。
尽管索引提供了一种快速访问数据的途径，但它们减缓了数据修改语句，因为当插入、修改和删除时，需要额外的负担来维护索引。

在决策支持系统中（DSS），定义更多的索引能帮助你的查询并且不会带来太多的性能问题，因为这些数据相对来讲是静态的并且不会频繁修改。你典型地会加载数据、创建索引。只要你需要索引来支持用户查询，并且它们能获得相当不错的响应时间，太多的索引的缺点只是不被使用的索引所浪费的空间。

另一方面，在OLTP环境下，太多的索引可能导致相当大的性能下降，特别是，假如一个表中索引数量超过4或5个。仔细想下，每个单行插入至少是一个数据页的写或者是为表中的每个索引所进行的更多索引页写（依赖于页分裂是否发生）。若有8个非聚集索引，单行插入最少将有9次写数据库，所以，对OLTP环境，你必须创建尽可能少的索引——典型地需要支持修改和删除操作的索引和你的关键查询，以及强制你唯一性约束的索引。

所以在理想世界中，自然的解决方法是，在DSS环境下创建许多索引，在OLTP环境下创建少许索引。不幸的是，在真实世界中，你典型地需要支持DSS和OLTP。你如何来解决两种环境下的对索引要求的竞争？为了满足DSS和OLTP应用的索引需求需要一些平衡技术。

其中一种方法是分别创建两个数据库——一个为DSS应用另外一个为OLTP。明显，这种方法需要一些方法来保持数据库的同步。这种方法选择依靠如何更新最新的DSS数据库。假如你更新的时间总是滞后的，你可以考虑使用dump-and-load机制，比如Log Shipping 或者周期性地数据库存储。如果你的DSS系统要求up-to-the -minute 并发，你可能会考虑使用replication技术。

另外一种选择是在日常工作中只为OLTP提供要求的索引。在忙的时间创建DSS查询和报表需要的索引。当DSS报表完成后，删除这些额外的报表。注意这种方法假定创建额外的索引需要的时间可以用加速DSS查询所获得时间得到补偿。

所以，小心选择索引以在数据搜索和数据修改性能之间提供一个平衡。应用的环境通常决定着索引的选择。例如，如果应用主要是OLTP类型，创建太多的索引可能会影响系统的性能。另一方面，应用可能是一个DSS类型的，在这种情况下，可以创建多一些的索引。