Nonclustered index和clustered index区别

这是我在一本SQL 2005 EXPRESS教程上看到的，介绍Nonclustered index和clustered index区别的片段，很好，故贴之：

 Determining What Makes a Good Index
To create an index on a table, you have to specify which columns are contained within the index.
Columns in an index do not have to all be of the same data type. You should be aware that there is a
limit of 16 columns on an index, and the total amount of data for the index columns within a row
cannot be more than 900 bytes. To be honest, if you get to an index that contains more than four or
five columns, you should stand back and reevaluate the index definition. Sometimes you’ll have
more than five columns, but you really should double-check.
It is possible to get around this restriction and have an index that does include columns that
are not part of the key: the columns are tagged onto the end of the index. This will mean that the
index takes up more space, but if it means that SSE can retrieve all of the data from an index search,
then it will be faster. However, to reiterate, if you are going down this route for indexes, perhaps you
need to look at your design.
In the sections that follow, we’ll examine some of the factors that can determine whether an
index is good:
• Using “low-maintenance” columns
• Using primary and foreign keys
• Being able to find a specific record
• Using covering indexes
• Looking for a range of information
• Keeping the data in order
Using Low-Maintenance Columns
As I’ve indicated, for nonclustered indexes the actual index data is separate from the table data,
although both can be stored in the same area or in different areas (e.g., on different hard drives). To
reiterate, this means that when you insert a record into a table, the information from the columns
included in the index is copied and inserted into the index area. So, if you alter data in a column
within a table, and that column has been defined as making up an index, SSE also has to alter the
data in the index. Instead of only one update being completed, two will be completed. If the table
has more than one index, and in more than one of those indexes is a column that is to be updated a
great deal, there may be several disk writes to perform when updating just one record. While this
will result in a performance reduction for data-modification operations, appropriate indexing will
balance this out by greatly increasing the performance of data-retrieval operations.
Therefore, data that is low maintenance—namely, columns that are not heavily updated—
could become an index and would make a good index. The fewer disk writes that SSE has to do, the
faster the database will be, as well as every other database within that SSE instance. Don’t let this
statement put you off. If you feel that data within a table is retrieved more often than it is modified,
or if the performance of the retrieval is more critical than the performance of the modification, then
do look at including the column within the index.
In the example application we’re building, each month we need to update a customer’s bank
balance with any interest gained or charged. However, we have a nightly job that wants to check for
clients who have between $10,000 and $50,000, as the bank can get a higher rate of deposit with the
Federal Reserve on those sorts of amounts. A client’s bank balance will be constantly updated, but
an index on this sort of column could speed up the overnight deposit check program. Before the
index in this example is created, we need to determine whether the slight performance degradation
in the updating of the balances is justified by the improvement of performance of the deposit check
program.