The following tasks make up our recommended strategy for creating indexes:

Design the index.
Index design is a critical task. Index design includes determining which columns to use, selecting the index type (for example, clustered or nonclustered), selecting appropriate index options, and determining filegroup or partition scheme placement. For more information, see Designing Indexes.

Determine the best creation method. Indexes are created in the following ways:

By defining a PRIMARY KEY or UNIQUE constraint on a column by using CREATE TABLE or ALTER TABLE
The SQL Server 2005 Database Engine automatically creates a unique index to enforce the uniqueness requirements of a PRIMARY KEY or UNIQUE constraint. By default, a unique clustered index is created to enforce a PRIMARY KEY constraint, unless a clustered index already exists on the table, or you specify a unique nonclustered index. By default, a unique nonclustered index is created to enforce a UNIQUE constraint unless a unique clustered index is explicitly specified and a clustered index on the table does not exist.
Index options and index location, filegroup or partition scheme, can also be specified.
An index created as part of a PRIMARY KEY or UNIQUE constraint is automatically given the same name as the constraint name. For more information, see PRIMARY KEY Constraints and UNIQUE Constraints.

By creating an index independent of a constraint by using the CREATE INDEX statement, or New Index dialog box in SQL Server Management Studio Object Explorer
You must specify the name of the index, table, and columns to which the index applies. Index options and index location, filegroup or partition scheme, can also be specified. By default, a nonclustered, nonunique index is created if the clustered or unique options are not specified.

Create the index.
Whether the index will be created on an empty table or one that contains data is an important factor to consider. Creating an index on an empty table has no performance implications at the time the index is created; however, performance will be affected when data is added to the table.
Creating indexes on large tables should be planned carefully so database performance is not hindered. The preferred way to create indexes on large tables is to start with the clustered index and then build any nonclustered indexes. Consider setting the ONLINE option to ON when you create indexes on existing tables. When set to ON, long-term table locks are not held enabling queries or updates to the underlying table to continue. For more information, see Performing Index Operations Online.

The index key of a clustered index cannot contain varchar columns that have existing data in the ROW_OVERFLOW_DATA allocation unit. If a clustered index is created on a varchar column and the existing data is in the IN_ROW_DATA allocation unit, subsequent insert or update actions on the column that would push the data off-row will fail.

The time taken to physically create an index is largely dependent on the disk subsystem. Important factors to consider are the following:

The recovery model of the database. The bulk-logged recovery model provides greater performance and reduced log-space consumption during the index creation operation than full recovery. However, bulk-logged recovery reduces the flexibility for point-in-time recovery. For more information, see Choosing a Recovery Model for Index Operations.

The RAID (redundant array of independent disks) level used to store the database and transaction log files. Generally, RAID levels that use striping will have better I/O bandwidth.

Number of disks in the disk array, if RAID was used. More drives in the array increases data transfer rates proportionally.

Where the intermediate sort runs of the data is stored. Using the SORT_IN_TEMPDB option can reduce the time that is required to create an index when tempdb is on a different set of disks than the user database. For more information, see tempdb and Index Creation.

Creating the index offline or online.
When an index is created offline (the default), exclusive locks are held on the underlying table until the transaction creating the index has completed. The table is inaccessible to users while the index is being created.
In SQL Server 2005, you can specify the index be created online. When the online option is set to ON, long-term table locks are not held, enabling queries or updates to the underlying table to continue while the index is being created. Although we recommend online index operations, you should evaluate your environment and specific requirements. It may be better to run index operations offline. In doing this, users have restricted access the data during the operation, but the operation finishes faster and uses fewer resources. For more information, see Performing Index Operations Online.