Ok, so it's been a while, but we're finally onto index metadata. We have three types of indexes in SQL Server, Relational, XML, Spatial. Okay, so that's really only three types of index and last time I said there were four, but the metadata for statistics is very similar, and we'll cover that next time. Our main table for indexes is [sys].[indexes] - with further information available in [sys].[xml_indexes] and [sys].[spatial_indexes]. For the columns participating in indexes, we will look at [sys].[index_columns].
So let's look at the most basic data first, from [sys].[indexes]:
object_id | This is the ID of the object that the index is created on. |
|---|---|
name | This is the name of the index. Each object cannot have more than index with the same name, but indexes on different objects can have the same names. If this is NULL, then the index represents a heap, which means the table has no clustered index - this is a universally bad thing. |
index_id | This is the ID of the index - and is unique per object. However, the index ID also has special meaning:
|
type | This column gives us an explicit type reference for the index:
|
type_desc | This is the description that relates to the value in the type column. |
is_unique | This will be 1 if the index enforces uniqueness, either because it was created using CREATE UNIQUE INDEX, or because it is enforcing a unique or primary key constraint. |
data_space_id | This is the ID of the data space in which the data for the index is stored. Note that because heaps and clustered indexes actually store the data of the underlying object, these indexes tell us where the actual data is stored. |
ignore_dup_key | This is 1 if the IGNORE_DUP_KEY option is ON for the index. |
is_primary_key | This is 1 if the index was created to enforce a PRIMARY KEY constraint. These types of indexes cannot be created directly, they are created by using ALTER TABLE to create the relevant type of constraint. |
is_unique_constraint | This is 1 if the index was created to enforce a UNIQUE constraint. These types of indexes cannot be created directly, they are created by using ALTER TABLE to create the relevant type of constraint. |
fill_factor | If this is non-zero, then it represents the specified FILLFACTOR when the index was created or updated. Fill factor represents a percentage of how full an index page will be when the index is newly created or rebuilt. If this is zero, then the database default value is used. The database default value is typically 0, which, interestingly, means 100 (i.e. full pages), but can be changed using sp_configure. |
is_padded | If this is 1, then PAD_INDEX was specified for the index, which means that the intermediate or leaf nodes of the index will also be spaced according to the fill_factor value. |
is_disabled | If this is 1 then the index is disabled. |
is_hypothetical | If this is 1, then the index is hypothetical, which means it can't actually be used for any useful querying. If you're wondering, hypothetical indexes are created by the database tuning advisor (DTA). |
allow_row_locks | This is 1 if the index allows row level locks. |
allow_page_locks | This is 1 if the index allows page level locks. |
has_filter | From SQL Server 2008 onwards, indexes could effectively have a WHERE clause specified for them, allowing indexes to be created on partial data. If the index has such a filter, then this column is 1. |
filter_definition | If the index has a filter, this contains the definition of it, otherwise this is NULL. |
Ok, cooking with gas. We've got a lot of information above, which enables us to specify everything we need to in order to re-create or understand indexes, apart from the columns that are present. So, let's look at the [sys].[index_columns] table to look at what we get there:
object_id | This is the ID of the object that the index is created on. |
|---|---|
index_id | This is the same as the index_id column from [sys].[indexes]. |
index_column_id | This is the ID of the column within in the index (i.e. giving a sequential number to the columns involved). |
column_id | This is the ID of the indexed column, and can be matched with [sys].[columns] for any given object_id value. |
key_ordinal | This gives the order in which the index key columns are specified - sorting the rows by this value gives you the key columns in the right order. |
partition_ordinal | This gives you order in which the columns are involved in partitioning for the index. Because partition functions currently only accept one parameter, this is either 0 or 1 (i.e. is not or is the partitioning key), but support for multiple parameter partition functions could be included in the future. |
is_descending_key | If this is 1, then the index is arranged with this key descending. |
is_included_column | If this is 1, then the column is an included column, and is present only on the data page level of the index. Applies to non-clustered indexes only |
That's given us everything we need to understand and re-create indexes. We can specify the key column list, with appropriate ordering, the inclusion list and even the partitioning key. So what extra information is available for XML indexes? Let's have a look at the extra columns we get in [sys].[xml_indexes] over and above what we get in [sys].[indexes]:
using_xml_index_id | For secondary XML indexes, a primary XML index is needed, and this column tells us what primary XML index the secondary index is referencing. For primary XML indexes, this column will contain NULL. |
|---|---|
secondary_type | This tells us the type of secondary XML index, if it is a secondary XML index:
|
secondary_type_desc | This is the description that relates to the value in the secondary_type column. |
So, there's not actually that much extra there - but it does cover what we need to know in order to accurately represent and recreate XML indexes.
What about spatial indexes? They have a lot of extra syntax over and above normal index creation, so we'd expect to find a lot of extra information in [sys].[spatial_indexes] over and above what we get in [sys].[indexes]:
spatial_index_type | This is the type of spacial index:
|
|---|---|
spatial_index_type_desc | This is the description that relates to the value in the spatial_index_type_desc column. |
tessellation_scheme | This is the style of the tessellation scheme, either GEOMETRY_GRID or GEOGRAPHY_GRID. GEOMETRY_GRID is a bounded grid in flat space, and GEOGRAPHY_GRID is an unbounded grid in curved space (accounting for the shape of the Earth). |
Hang on a minute. That wasn't the tasty snack we were expecting! Where is the information about bounding boxes for geometry grids, and the grid densities? For some unfathomable reason, this information is stored in [sys].[spatial_index_tessellations] - let's take a look:
object_id | This is the ID of the object that the index is created on. |
|---|---|
index_id | This is the same as the index_id column from [sys].[indexes]. |
tessellation_scheme | This is the style of the tessellation scheme, either GEOMETRY_GRID or GEOGRAPHY_GRID. GEOMETRY_GRID is a bounded grid in flat space, and GEOGRAPHY_GRID is an unbounded grid in curved space (accounting for the shape of the Earth). |
bounding_box_xmin | When using a GEOMETRY_GRID, these four values will define the bounding box in which the spatial index is defined. When using a GEOGRAPHY_GRID, the four values will be NULL. |
bounding_box_ymin | |
bounding_box_xmax | |
bounding_box_ymax | |
level_1_grid | Grid density appropriate grid level, and is one of the following values:
|
level_2_grid | |
level_3_grid | |
level_4_grid | |
level_1_grid_desc | Description of the grid density for the appropriate grid level, either LOW, MEDIUM or HIGH. |
level_2_grid_desc | |
level_3_grid_desc | |
level_4_grid_desc | |
cells_per_object | This is the number of cells per object, as specified in the index DML. |
That's better - now we've got the information we need for spatial indexes too. Statistics up next!