**usr* has a good post worth reading. I will add here from Microsofts Documentation.
First, you are not alone with Clustered-Indexes
. Honestly, the name itself is somewhat confusing (Structured-Indexes or Disk-Indexes would probably be better in SQL
).
Refer back to the official documentation from MSDN. Any alterations by me are in italics:
A Clustered Index is an on-disk structure of the table. This means the values are pointing to a physical location. This is why when you move the table you need to recreate the Index because the physical location has been altered.
Clustered
Clustered indexes sort and store the data rows in the table or view
based on their key values. These are the columns included in the index
definition. There can be only one clustered index per table, because
the data rows themselves can be sorted in only one order.
The only time the data rows in a table are stored in sorted order is
when the table contains a clustered index
. When a table has a
clustered index, the table is called a clustered table
. If a table has
no clustered index, its data rows are stored in an unordered structure
called a heap
.
Nonclustered
Nonclustered indexes have a structure separate from the data rows (like pointers, this is a logical ordering of the data that consumes a fraction of the physical disk space).
A nonclustered index contains the nonclustered index key values and each
key value entry has a pointer
to the data row that contains the key
value.
The pointer from an index row in a nonclustered index to a data row
is called a row locator
. The structure of the row locator depends on
whether the data pages are stored in a heap
or a clustered table
(think ordered).
- For a
heap
, a row locator is a pointer to the row.
- For a
clustered table
, the row locator is the clustered index key.
ABSTRACT VIEW:
- A table created is not necessarily a clustered (ordered) table.
- An index does not necessarily have to be unique. It is an abstract view of the table.
- Unique means that a value or set of values will not repeat themselves. If you wish to enforce this, you can add a constraint by the index (i.e.
UNIQUE CLUSTERED INDEX
) or a CONSTRAINT
such as PRIMARY KEY
if you wish this to be managed in the table structure itself.
- You may have multiple unique indexes since as long as the values are represented logically, they will not share the same value as another row pointer.
Consider you have Columns A, B, and C in a given table.
Column A was created with a UNIQUE CLUSTERED INDEX
. This means that either A already had an enforceable UNIQUE constraint (like PK
, UNIQUE
CONSTRAINT
) or was DECLARED EXPLICITLY.
A Column Group {B,C} could be a unique index so long as B and C never repeat itself together. In the same way, you could theoretically have indexes with the groups {A}, {B,C}, {A,C}, and every one of them be unique. Recall that an index is a logical ordering of the data so they likely will not have the same logical value (and thus are unique).
HOWEVER: unless the datatype, constraint (including the INDEX constraint), or table structure enforces a unique constraint on a COLUMN
, you should not assume the index is unique. Furthermore, you cannot create a UNIQUE
index if there are more than one rows containing the same combination of NULL
values since SQL Server
will treat them as the same value (NULL being unknown).
Will SQL Server
use your indexes, unique or not? Well that is another story and depends on a number of things. But hopefully you find this post helpful.
Sources:
MSDN - Clustered and Nonclustered Indexes Described