db_name(db_id()) as DatabaseName
, schema_name(t.schema_id) as SchemaName
, t.name as TableName
, i.name as IndexName
, i.type_desc as IndexType
, c.name as ColumnName
, typ.name as DataType
from sys.tables t
inner join sys.indexes i on t.object_id = i.object_id
inner join sys.index_columns ic on i.object_id = ic.object_id
and i.index_id = ic.index_id
inner join sys.columns c on ic.object_id = c.object_id
and ic.column_id = c.column_id
inner join sys.types typ on c.user_type_id = typ.user_type_id
and t.is_ms_shipped = 0
and i.is_hypothetical = 0
order by DatabaseName, SchemaName, TableName, IndexName, ic.is_included_column, ic.key_ordinal
Indexes directly affect the performance of database applications. This article uses analogies to describe how indexes work. The estimated execution plan feature of the Query Window is utilized to compare the performance of two queries in a batch.
SQL Server 2000 has indexed views, which can greatly improve database performance. However there are a number of restrictions on building the view, including the restriction against outer joins. So how can this work? New author Jean Charles Bulinckx brings us a technique that can help you get around this restriction.
There is nothing spectacular about using indexes per say. However, on many occasions I have come across a variety of SQL coders that never consider validating that the index they think they are using is efficient or even being used at all. We can all put indexes on the columns that we think will be required to satisfy individual queries, but how do we know if they will ever be used. You see, if the underlying table data is constructed, contains, or is ordered in a particular way, our indexes may never be used. One of the factors around the use of an index is its clustering factor and this is what this article is about.