重新组织 vs 重新生成索引
索引是数据库引擎中针对表(有时候也针对视图)建立的特别数据结构，用来帮助查找和整理数据。索引的重要性体现在能够使数据库引擎快速返回查询 结果。当对索引所在的基础数据表进行修改时(包括插入、删除和更新等操作)，会导致索引碎片的产生。当索引的逻辑排序和基础表或视图的物理排序不匹配时， 就会产生索引碎片。随着索引碎片的不断增多，查询响应时间就会变慢，查询性能也会下降。在SQL Server 2005中，要解决这个问题，要么重新组织索引要么重新生成索引。
重新组织VS重新生成
修复索引碎片的方法有两种：重新组织索引或重新生成索引。重新组织索引会对最外层数据页里的数据进行重新排序，并压缩索引页。重新组织的过程中 不会添加任何额外的数据，所以索引可能还残留着一定程度的碎片。重新组织索引操作不会占用很多系统资源，在运行过程中外部进程也能够对该索引所在的数据表 进行查询，所以能够说是联机(online)执行。
重新生成索引操作基本上删除掉目标索引并创建一个新索引。旧索引中的任何碎片都会被删除，新索引的逻辑排序将和对象的物理排序相匹配。由于整个 过程需要删除索引并重新创建，所以外部进程无法访问数据表，而且访问性能也大受影响。事实上，在重新生成索引的过程中，其他进程并不能完全锁定数据表。这 是重新生成索引的一大障碍。
联机重新生成索引
SQL Server 2005引进了以联机方式重新生成索引的能力，这样其他进程就能够在此过程中正常访问数据表，而且也就无需限制在非繁忙时段进行索引重新生成操作。
要做到联机操作，数据库引擎会采取若干特别配置，以便在重新生成索引的同时允许对该索引的访问。首先，将保留原始索引以供用户读取数据和对数据 进行修改。其次通过行版本控制(row versioning，在tempdb数据库存储旧版本的行的过程)使事务读取保持连贯性。在重新生成过程中，仿效旧索引创建一个新索引。任何改变原始索 引的数据修改操作都会在重新生成索引的过程中被SQL Server引用到新索引中。新索引不能读取，只能对其进行写入操作。关键的一点是，联机重新生成索引过程中必须为两个并发索引提供足够的磁盘空间来容纳 数据。重建进行的过程中，假如原始索引发生改变，SQL Server会利用一个映射索引来确定新索引中哪些记录需要进行相应修改。一旦重新生成的过程顺利完成，任何查询或数据修改操作都将指向新索引，同时删除 原始索引。
例子
联机重新生成索引的过程和一般的重新生成索引过程没有太大区别。但是，能够通过几个方法来完成整个重生过程。第一个方法就是简单地删除索 引，CREATE INDEX语句后加上一条DROP INDEX就能够。用这种方式重新生成索引会使数据表保持没有索引的状态直到新索引完全创建完毕。所以并不推荐使用这种方法来删除索引。
假如使用DROP_EXISTING语句，仍然能够用CREATE INDEX来重新生成索引。这个特点使我们能够改变指定索引的定义，并且使数据库管理员能够把索引的存储位置改到另外一个文档组或分区里。
ALTER INDEX语句使我们能够重新生成数据表上的聚集索引和任何非聚集索引。这个语句的缺点是，您不能改变索引的定义。这些语句都含有能够联机生成索引的选项。
以下的语句是用来重新生成FlightHistory表上的聚集索引(位于FlightID列)。在这个过程中，既存的索引将会被删除，但是由于指定了ONLINE选项，所以在操作过程中该索引还能够被访问。
| 以下是引用片段： CREATE CLUSTERED INDEX cl_FlightHistory_FlightID ON FlightHistory(FlightID) WITH(DROP_EXISTING = ON, ONLINE = ON) |
下面的语句和上面的很相似，但是改变实际的索引定义，包含了一个额外列。索引还是按照相同的方式重新生成。
以下是引用片段：CREATE CLUSTERED INDEX cl_FlightHistory_FlightID ON FlightHistory(FlightID ASC, FlightDate ASC)
WITH(DROP_EXISTING = ON, ONLINE = ON)