On Thu, 2004-08-26 at 12:30, Magnus Hagander wrote:
> Almost the same for MSSQL. The clustered index is always forced unique.
> If you create a non-unique clustered index, SQLServer will internally
> pad it with random (or is it sequential? Can't remember right now) data
> to make each key unique. The clustered index contains all the data
> fields - both the index key and the other columns from the database.
>
> It does support non-clustered indexes as well on the same table. Any
> "secondary index" will then contain the index key and the primary key
> value. This means a lookup in a non-clustered index means a two-step
> index lookup: First look in the non-clustered index for the clustered
> key. Then look in the clustered index for the rest of the data.
Ah, okay. I see how that would work for a secondary index, though it
would make for a slow secondary index. Neat workaround. For all I
know, current versions of Oracle may support secondary indexes on
index-organized tables; all this Postgres usage over the last couple
years has made my Oracle knowledge rusty.
> IIRC, SQL Server always creates clustered indexes by default for primary
> keys.
That would surprise me actually. For some types of tables, e.g. ones
with multiple well-used indexes or large rows, index-organizing the heap
could easily give worse performance than a normal index/heap pair
depending on access patterns. It also tends to be more prone to having
locking contention under some access patterns. This is one of those
options that needs to be used knowledgeably; it is not a general
architectural improvement that you would want to apply to every table
all the time.
J. Andrew Rogers