CREATE INDEX (Transact-SQL)

Применимо: SQL Server База данных SQL Azure Управляемый экземпляр SQL Azure azure Synapse Analytics Analytics Platform System (PDW)

Создает реляционный индекс для таблицы или представления. Он также называется индексом rowstore, так как является кластеризованным или некластеризованным индексом сбалансированного дерева. Индекс rowstore можно создать до заполнения таблицы данными. Индекс rowstore позволяет повысить производительность запросов, особенно в том случае, если запросы выбирают определенные столбцы или им требуются значения, которые должны быть отсортированы в определенном порядке.

Примечание.

В документации термин B-tree обычно используется в ссылке на индексы. В индексах rowstore ядро СУБД реализует дерево B+. Это не относится к индексам columnstore или индексам в таблицах, оптимизированных для памяти. Дополнительные сведения см. в руководстве по архитектуре и проектированию индексов SQL Sql Server и Azure.

Azure Synapse Analytics и Система платформы аналитики (PDW) в настоящее время не поддерживает ограничения уникальности. Примеры, ссылающиеся на ограничения уникальности применимы только к SQL Server и Базе данных SQL.

Дополнительные сведения о правилах проектирования индексов см. в статье Руководство по проектированию индексов SQL Server.

Примеры:

1. Создание некластеризованного индекса в таблице или представлении

   CREATE INDEX index1 ON schema1.table1 (column1);
   

2. Создание кластеризованного индекса в таблице и использование имени, состоящего из трех элементов, для таблицы

   CREATE CLUSTERED INDEX index1 ON database1.schema1.table1 (column1);
   

3. Создание некластеризованного индекса с ограничением уникальности и указание порядка сортировки

   CREATE UNIQUE INDEX index1 ON schema1.table1 (column1 DESC, column2 ASC, column3 DESC);
   

Основной сценарий.

Начиная с SQL Server 2016 (13.x); и Базы данных SQL, некластеризованный индекс можно использовать в индексе columnstore для повышения производительности запросов хранилища данных. Дополнительные сведения см. в статье Хранилище данных для индексов columnstore.

Дополнительные типы индексов описаны в следующих статьях:

• CREATE XML INDEX
• CREATE SPATIAL INDEX
• CREATE COLUMNSTORE INDEX

Соглашения о синтаксисе Transact-SQL

Синтаксис

Синтаксис SQL Server, База данных SQL Azure, Управляемый экземпляр SQL Azure

CREATE [ UNIQUE ] [ CLUSTERED | NONCLUSTERED ] INDEX index_name
    ON <object> ( column [ ASC | DESC ] [ ,...n ] )
    [ INCLUDE ( column_name [ ,...n ] ) ]
    [ WHERE <filter_predicate> ]
    [ WITH ( <relational_index_option> [ ,...n ] ) ]
    [ ON { partition_scheme_name ( column_name )
         | filegroup_name
         | default
         }
    ]
    [ FILESTREAM_ON { filestream_filegroup_name | partition_scheme_name | "NULL" } ]

[ ; ]

<object> ::=
{ database_name.schema_name.table_or_view_name | schema_name.table_or_view_name | table_or_view_name }

<relational_index_option> ::=
{
    PAD_INDEX = { ON | OFF }
  | FILLFACTOR = fillfactor
  | SORT_IN_TEMPDB = { ON | OFF }
  | IGNORE_DUP_KEY = { ON | OFF }
  | STATISTICS_NORECOMPUTE = { ON | OFF }
  | STATISTICS_INCREMENTAL = { ON | OFF }
  | DROP_EXISTING = { ON | OFF }
  | ONLINE = { ON [ ( <low_priority_lock_wait> ) ] | OFF }
  | RESUMABLE = { ON | OFF }
  | MAX_DURATION = <time> [MINUTES]
  | ALLOW_ROW_LOCKS = { ON | OFF }
  | ALLOW_PAGE_LOCKS = { ON | OFF }
  | OPTIMIZE_FOR_SEQUENTIAL_KEY = { ON | OFF }
  | MAXDOP = max_degree_of_parallelism
  | DATA_COMPRESSION = { NONE | ROW | PAGE }
     [ ON PARTITIONS ( { <partition_number_expression> | <range> }
     [ , ...n ] ) ]
  | XML_COMPRESSION = { ON | OFF }
     [ ON PARTITIONS ( { <partition_number_expression> | <range> }
     [ , ...n ] ) ]
}

<filter_predicate> ::=
    <conjunct> [ AND ] [ ...n ]

<conjunct> ::=
    <disjunct> | <comparison>

<disjunct> ::=
        column_name IN (constant ,...n)

<comparison> ::=
        column_name <comparison_op> constant

<comparison_op> ::=
    { IS | IS NOT | = | <> | != | > | >= | !> | < | <= | !< }

<low_priority_lock_wait>::=
{
    WAIT_AT_LOW_PRIORITY ( MAX_DURATION = <time> [ MINUTES ] ,
                          ABORT_AFTER_WAIT = { NONE | SELF | BLOCKERS } )
}

<range> ::=
<partition_number_expression> TO <partition_number_expression>

Реляционный индекс с обратной совместимостью

Внимание

Структура синтаксиса обратно совместимого реляционного индекса будет удалена в будущей версии SQL Server. Избегайте ее использования в новых разработках и запланируйте изменение приложений, которые пользуются ею сейчас. Используйте структуру синтаксиса, указанную в <relational_index_option> вместо нее.

CREATE [ UNIQUE ] [ CLUSTERED | NONCLUSTERED ] INDEX index_name
    ON <object> ( column_name [ ASC | DESC ] [ ,...n ] )
    [ WITH <backward_compatible_index_option> [ ,...n ] ]
    [ ON { filegroup_name | "default" } ]

<object> ::=
{
    [ database_name. [ owner_name ] . | owner_name. ]
    table_or_view_name
}

<backward_compatible_index_option> ::=
{
    PAD_INDEX
  | FILLFACTOR = fillfactor
  | SORT_IN_TEMPDB
  | IGNORE_DUP_KEY
  | STATISTICS_NORECOMPUTE
  | DROP_EXISTING
}

Синтаксис для Azure Synapse Analytics и Parallel Data Warehouse

CREATE CLUSTERED COLUMNSTORE INDEX index_name
    ON [ database_name . [ schema ] . | schema . ] table_name
    [ORDER (column[,...n])]
    [WITH ( DROP_EXISTING = { ON | OFF } )]
[;]


CREATE [ CLUSTERED | NONCLUSTERED ] INDEX index_name
    ON [ database_name . [ schema ] . | schema . ] table_name
        ( { column [ ASC | DESC ] } [ ,...n ] )
    WITH ( DROP_EXISTING = { ON | OFF } )
[;]

Аргументы

UNIQUE

Создает уникальный индекс для таблицы или представления. Уникальным является индекс, в котором не может быть двух строк с одним и тем же значением ключа индекса. Кластеризованный индекс представления должен быть уникальным.

Компонент Database Engine не позволяет создать уникальный индекс по столбцам, которые уже содержат повторяющиеся значения, даже если параметру IGNORE_DUP_KEY присвоено значение ON. При попытке ядро СУБД отображается сообщение об ошибке. Прежде чем создавать уникальный индекс по такому столбцу или столбцам, необходимо удалить все повторяющиеся значения. Столбцы, используемые в уникальном индексе, должны иметь свойство NOT NULL, т. к. при создании индекса значения NULL рассматриваются как повторяющиеся.

CLUSTERED

Создает индекс, в котором логический порядок значений ключа определяет физический порядок соответствующих строк в таблице. На нижнем (конечном) уровне кластеризованного индекса хранятся действительные строки данных таблицы. Для таблицы или представления в каждый момент времени может существовать только один кластеризованный индекс.

Представление с уникальным кластеризованным индексом называется индексированным. Создание уникального кластеризованного индекса физически материализует представление. Уникальный кластеризованный индекс для представления должен быть создан до того, как для этого же представления будут определены какие-либо другие индексы. Дополнительные сведения см. в разделе Создание индексированных представлений.

Создавайте кластеризованные индексы до создания любых некластеризованных. При создании кластеризованного индекса все существующие некластеризованные индексы таблицы перестраиваются.

Если CLUSTERED не указан, создается некластеризованный индекс.

Примечание.

Поскольку конечный уровень кластеризованного индекса и страницы данных — это по определению одно и то же, создание кластеризованного индекса и использование предложения ON partition_scheme_name или ON filegroup_name приводят к перемещению таблицы из файловой группы, в которой она была создана, в новую схему секционирования или файловую группу. Прежде чем создавать таблицы или индексы в определенных файловых группах, проверьте, какие группы доступны, и убедитесь в том, что в этих группах достаточно свободного места для индекса.

В некоторых случаях создание кластеризованного индекса может привести к включению ранее отключенных индексов. Дополнительные сведения см. в разделах Включение индексов и ограничений и Отключение индексов и ограничений.

NONCLUSTERED

Создает индекс, задающий логическое упорядочение для таблицы. Логический порядок строк в некластеризованном индексе не влияет на их физический порядок.

Каждая таблица может содержать до 999 некластеризованных индексов независимо от способа их создания: неявно с помощью ограничений PRIMARY KEY и UNIQUE или явно с помощью инструкции CREATE INDEX.

Для индексированных представлений некластеризованные индексы могут создаваться только в случае, если уже определен уникальный кластеризованный индекс.

Если не указано иное, по умолчанию используется некластеризированный индекс.

index_name

Имя индекса. Имена индексов должны быть уникальными в пределах таблицы или представления, но их уникальность не обязательна в пределах базы данных. Имена индексов должны удовлетворять правилам для идентификаторов.

column

Столбец или столбцы, на которых основан индекс. Имена одного или нескольких столбцов для создания комбинированного индекса. Столбцы, которые должны быть включены в составной индекс, указываются в скобках за аргументом table_or_view_name в порядке сортировки.

В один ключ составного индекса могут входить до 32 столбцов. Все столбцы ключа составного индекса должны находиться в одной таблице или одном и том же представлении. Максимально допустимый размер значений составного индекса составляет 900 байтов для кластеризованного индекса или 1700 для некластеризованного индекса. Ограничения — 16 столбцов и 900 байт для версий до База данных SQL и SQL Server 2016 (13.x).

Столбцы с типами данных LOB ntext, text, varchar(max), nvarchar(max), varbinary(max), xml или image нельзя указать в качестве столбцов для индекса. Кроме того, определение представления не может включать столбцы типов ntext, text или image, даже если они не указаны в инструкции CREATE INDEX.

Можно создавать индексы на столбцах с определяемым пользователем типом данных CLR, если этот тип поддерживает двоичное упорядочение. Можно также создавать индексы на вычисляемых столбцах, определенных как вызовы методов для столбцов с определяемыми пользователем типами данных, если эти методы помечены как детерминированные и не выполняют операции доступа к данным. Дополнительные сведения об индексировании столбцов с определяемыми пользователем типами данных CLR см. в разделе Определяемые пользователем типы данных CLR.

[ ASC | DESC ]

Определяет сортировку значений заданного столбца индекса: по возрастанию или по убыванию. Значение по умолчанию — ASC.

INCLUDE (column [ ,... n ] )

Указывает неключевые столбцы, добавляемые на конечный уровень некластеризованного индекса. Некластеризованный индекс может быть уникальным или неуникальным.

Имена столбцов в списке INCLUDE не могут повторяться и не могут использоваться одновременно в качестве ключевых и неключевых. Некластеризованные индексы всегда содержат столбцы кластеризованного индекса, если для таблицы определен кластеризованный индекс. Дополнительные сведения см. в статье Create Indexes with Included Columns.

Допускаются данные всех типов, за исключением text, ntextи image. Начиная с SQL Server 2012 (11.x) и Базы данных SQL Azure, если один из указанных неключевых столбцов является varchar(max), nvarchar(max)или varbinary(max),, индекс можно создать или перестроить с помощью параметра ONLINE.

Вычисляемые столбцы, являющиеся детерминированными и точными или неточными, могут быть включенными столбцами. Вычисляемые столбцы, производные от типов данных image, ntext, text, varchar(max), nvarchar(max), varbinary(max)и xml, могут быть включены в неключевые столбцы, если типы данных вычисляемого столбца допускаются в качестве столбца для включения. Дополнительные сведения см. в разделе Индексы вычисляемых столбцов.

Сведения о создании XML-индекса см. в описании CREATE XML INDEX.

WHERE <filter_predicate>

Создает отфильтрованный индекс путем указания строк для включения в индекс. Отфильтрованный индекс должен быть некластеризованным индексом для таблицы. Создается отфильтрованная статистика для строк данных отфильтрованного индекса.

Предикат фильтра использует простую логику сравнения и не может ссылаться на вычисляемый столбец, столбец определяемого пользователем типа, столбец типа пространственных данных или столбец типа hierarchyID. Сравнения с помощью литералов NULL с операторами сравнения недопустимы. Используйте вместо них операторы IS NULL и IS NOT NULL.

Далее приведено несколько примеров использования предикатов фильтра для таблицы Production.BillOfMaterials:

WHERE StartDate > '20000101' AND EndDate <= '20000630'

WHERE ComponentID IN (533, 324, 753)

WHERE StartDate IN ('20000404', '20000905') AND EndDate IS NOT NULL

Отфильтрованные индексы не применяются к XML-индексам и полнотекстовым индексам. Для индексов UNIQUE только выбранные строки должны иметь уникальные значения индексов. Отфильтрованные индексы не поддерживают параметр IGNORE_DUP_KEY.

ON partition_scheme_name ( column_name )

Задает схему секционирования, которая определяет файловые группы, соответствующие секциям секционированного индекса. Схема секционирования должна быть создана в базе данных путем выполнения инструкции CREATE PARTITION SCHEME или ALTER PARTITION SCHEME. column_name указывает столбец, по которому будет секционирован индекс. Столбец должен соответствовать по типу данных, длине и точности аргументу функции секционирования, используемой аргументом partition_scheme_name. column_name необязательно должен соответствовать столбцам из определения индекса. Можно указать любой столбец базовой таблицы, за исключением случая секционирования индекса UNIQUE, когда аргумент column_name должен быть выбран из используемых в качестве уникального ключа. Это ограничение позволяет ядро СУБД проверять уникальность значений ключей только в одной секции.

Примечание.

При секционировании не уникального кластеризованного индекса ядро СУБД по умолчанию добавляет столбец секционирования в список кластеризованных ключей индекса, если он еще не указан. При секционировании неукластеризованного индекса ядро СУБД добавляет столбец секционирования в виде неключевых (включенных) столбцов индекса, если он еще не указан.

Если partition_scheme_name или filegroup не задан, а таблица секционирована, индекс помещается в ту же схему секционирования и с тем же столбцом секционирования, что и для базовой таблицы.

Примечание.

Для XML-индекса задать схему секционирования невозможно. Если базовая таблица секционирована, XML-индекс использует ту же схему секционирования, что и таблица.

Дополнительные сведения об индексах секционирования см. в разделе Секционированные таблицы и индексы.

ON filegroup_name

Создает заданный индекс в указанной файловой группе. Если местоположение не указано и таблица или представление не секционированы, индекс использует ту же файловую группу, что и базовая таблица или базовое представление. Файловая группа должна существовать.

ON "default"

Создает указанный индекс для той же файловой группы или схемы секционирования, к которой относится таблица или представление.

В этом контексте default не является ключевым словом. Это идентификатор файловой группы по умолчанию, который должен иметь разделители, как в выражении ON "default" или ON [default]. Если указано значение "default" (по умолчанию), параметр QUOTED_IDENTIFIER должен иметь значение ON для текущего сеанса. Этот параметр принимается по умолчанию. Дополнительные сведения см. в описании SET QUOTED_IDENTIFIER.

Примечание.

"default" не указывает файловую группу по умолчанию для базы данных в контексте CREATE INDEX. В случае с инструкцией CREATE TABLE поведение иное: значение "default" указывает расположение таблицы в файловой группе по умолчанию для базы данных.

[ FILESTREAM_ON { filestream_filegroup_name | partition_scheme_name | "NULL" } ]

Указывает размещение данных FILESTREAM для таблицы при создании кластеризованного индекса. Предложение FILESTREAM_ON позволяет перемещать данные FILESTREAM в другую файловую группу FILESTREAM или схему секционирования.

Аргумент filestream_filegroup_name указывает имя файловой группы FILESTREAM. В файловой группе должен быть определен один файл для файловой группы с помощью инструкции CREATE DATABASE или ALTER DATABASE, иначе возникает ошибка.

Если таблица секционирована, должно быть включено предложение FILESTREAM_ON и указана схема секционирования файловых групп FILESTREAM, использующая ту же функцию и те же столбцы секционирования, что и схема секционирования для таблицы. В противном случае произойдет ошибка.

Если таблица не секционирована, столбец FILESTREAM не может быть секционирован. Данные FILESTREAM для этой таблицы необходимо хранить в отдельной файловой группе, указанной в предложении FILESTREAM_ON.

FILESTREAM_ON NULL можно указать в инструкции CREATE INDEX, если создается кластеризованный индекс и таблица не содержит столбец FILESTREAM.

Дополнительные сведения см. в разделе FILESTREAM (SQL Server).

<object>::=

Полное или неполное имя индексируемого объекта.

database_name

Имя базы данных.

schema_name

Имя схемы, которой принадлежит таблица или представление.

table_or_view_name

Имя индексируемой таблицы или представления.

Чтобы создать индекс для представления, это представление оно должно быть определено с параметром SCHEMABINDING. Прежде чем создавать любой некластеризованный индекс для представления, необходимо создать уникальный кластеризованный индекс. Дополнительные сведения об индексированных представлениях см. в разделе "Примечания".

Начиная с SQL Server 2016 (13.x), объект может быть таблицей, хранящейся с кластеризованным индексом columnstore.

База данных SQL Azure поддерживает трехкомпонентный формат имени database_name.[schema_name]. object_name, если database_name является текущей базой данных или database_name, tempdb и object_name начинается с #.

<>relational_index_option::=

Указывает параметры, которые должны использоваться при создании индекса.

PAD_INDEX = { ON | OFF }

Определяет разреженность индекса. Значение по умолчанию — OFF.

DNS
Процент свободного места, определяемый параметром fillfactor, применяется к страницам индекса промежуточного уровня.

OFF или fillfactor не указан
Страницы промежуточного уровня заполняются почти полностью, при этом остается достаточно места по крайней мере для одной строки максимального размера, возможного в этом индексе при заданном наборе ключей на промежуточных страницах.

Параметр PAD_INDEX имеет смысл только в случае, если указан параметр PAD_INDEX, так как использует процентное значение, указанное в нем. Если процент, заданный аргументом FILLFACTOR, недостаточно велик для размещения одной строки, ядро СУБД внутренне переопределит это значение, чтобы обеспечить минимум. Количество строк на странице индекса промежуточного уровня никогда не бывает менее двух даже при самых малых значениях аргумента fillfactor.

Для обратной совместимости синтаксиса аргумент WITH PAD_INDEX эквивалентен WITH PAD_INDEX = ON.

FILLFACTOR = fillfactor

Указывает, на сколько процентов ядро СУБД должно заполнять конечный уровень каждой страницы индекса во время создания и изменения индекса. Значение fillfactor должно быть целым числом от 1 до 100. Значения коэффициентов заполнения 0 и 100 идентичны. Если значение fillfactor равно 100, ядро СУБД создает индексы с конечными страницами, заполненными емкостью.

Аргумент FILLFACTOR действует только при создании или перестройке индекса. Ядро СУБД не сохраняет динамически указанный процентный объем свободного места на страницах.

Увидеть коэффициент заполнения можно в таблице fill_factor в sys.indexes.

Внимание

Создание кластеризованного индекса с FILLFACTOR менее чем 100 влияет на объем дискового пространства, которое занимает данные, так как ядро СУБД перераспространяет данные при создании кластеризованного индекса.

Дополнительные сведения см. в статье Указание коэффициента заполнения для индекса.

SORT_IN_TEMPDB = { ON | OFF }

Указывает, сохранять ли временные результаты сортировки в базе данных tempdb. Значение по умолчанию — OFF, за исключением функции гипермасштабирования базы данных SQL Azure. Для всех операций построения индекса в режиме Гипермасштабирования SORT_IN_TEMPDB всегда включен независимо от указанного параметра, если не используется возобновляемое перестроение индекса.

DNS
Промежуточные результаты сортировки, которые используются при индексировании, хранятся в базе данных tempdb. Это может уменьшить время, необходимое для создания индекса, если база данных tempdb и база данных пользователя находятся на разных наборах дисков. Однако это увеличивает использование места на диске, которое используется при индексировании.

ВЫКЛ.
Промежуточные результаты сортировки хранятся в той же базе данных, где и индекс.

Кроме места в базе данных пользователя, необходимого для создания индекса, требуется примерно столько же дополнительного места в базе данных tempdb для хранения промежуточных результатов сортировки. Дополнительные сведения см. в разделе Параметр SORT_IN_TEMPDB для индексов.

Для обратной совместимости синтаксиса аргумент WITH SORT_IN_TEMPDB эквивалентен WITH SORT_IN_TEMPDB = ON.

IGNORE_DUP_KEY = { ON | OFF }

Определяет ответ на ошибку, случающуюся, когда операция вставки пытается вставить в уникальный индекс повторяющиеся значения ключа. Параметр IGNORE_DUP_KEY применяется только к операциям вставки, производимым после создания или перестроения индекса. Параметр не работает во время выполнения инструкции CREATE INDEX, ALTER INDEX или UPDATE. Значение по умолчанию — OFF.

DNS
Если в уникальный индекс вставляются повторяющиеся значения ключа, выводится предупреждающее сообщение. С ошибкой завершаются только строки, нарушающие ограничение уникальности.

ВЫКЛ.
Если в уникальный индекс вставляются повторяющиеся значения ключа, выводится сообщение об ошибке. Будет выполнен откат всей операции INSERT.

Для IGNORE_DUP_KEY нельзя установить значение ON для индексов, создаваемых для представлений, неуникальных индексов, XML-индексов, пространственных индексов и фильтруемых индексов.

Для просмотра значения IGNORE_DUP_KEY используйте sys.indexes.

Для обратной совместимости синтаксиса аргумент WITH IGNORE_DUP_KEY эквивалентен WITH IGNORE_DUP_KEY = ON.

STATISTICS_NORECOMPUTE = { ON | OFF}

Указывает, выполнялся ли перерасчет статистики распределения. Значение по умолчанию — OFF.

DNS
Устаревшие статистики не пересчитываются автоматически.

ВЫКЛ.
Автоматическое обновление статистических данных включено.

Чтобы восстановить автоматическое обновление статистики, установите для параметра STATISTICS_NORECOMPUTE значение OFF или выполните UPDATE STATISTICS без предложения NORECOMPUTE.

Внимание

Отключение автоматического пересчета статистики распределения может помешать оптимизатору запросов выбрать оптимальные планы выполнения запросов, обращенных к таблице.

Для обратной совместимости синтаксиса аргумент WITH STATISTICS_NORECOMPUTE эквивалентен WITH STATISTICS_NORECOMPUTE = ON.

STATISTICS_INCREMENTAL = { ON | OFF }

Область применения: SQL Server (начиная с SQL Server 2014 (12.x)) и База данных SQL Azure

При значении ON статистики создаются как статистики отдельно по секциям. При отключении дерева статистики удаляется, а SQL Server повторно вычисляет статистику. Значение по умолчанию — OFF.

Если статистики по секциям не поддерживаются, параметр пропускается и выводится предупреждение. Добавочные статистики не поддерживаются для следующих типов статистических данных.

• Статистики, созданные с индексами, не выровненными по секциям для базовой таблицы.
• Статистики, созданные в доступных для чтения базах данных-получателях AlwaysOn.
• Статистики, созданные в базах данных, доступных только для чтения.
• Статистики, созданные по фильтрованным индексам.
• Статистика, созданная по представлениям.
• Статистики, созданные по внутренним таблицам.
• Статистики, созданные с пространственными индексами или XML-индексами.

DROP_EXISTING = { ON | OFF }

Параметр для удаления и перестроения существующего кластеризованного или некластеризованного индекса с измененными спецификациями столбцов и сохранения того же имени для индекса. Значение по умолчанию — OFF.

DNS
Указывает удалить и перестроить существующий индекс, который должен иметь имя, совпадающее с именем параметра index_name.

ВЫКЛ.
Указывает не удалять и перестраивать существующий индекс. SQL Server отображает ошибку, если индекс с указанным именем уже существует.

С помощью DROP_EXISTING можно изменить:

• некластеризованный индекс rowstore на кластеризованный индекс rowstore.

В случае DROP_EXISTING нельзя изменить:

• кластеризованный индекс rowstore на некластеризованный индекс rowstore;
• кластеризованный индекс columnstore на индекс rowstore любого типа.

Для обратной совместимости синтаксиса аргумент WITH DROP_EXISTING эквивалентен WITH DROP_EXISTING = ON.

ONLINE = { ON | OFF }

Определяет, будут ли базовые таблицы и связанные индексы доступны для запросов и изменения данных во время операций с индексами. Значение по умолчанию — OFF.

Внимание

Операции с индексами в Сети недоступны в каждом выпуске Microsoft SQL Server. Список функций, поддерживаемых выпусками SQL Server, см. в выпусках и поддерживаемых функциях SQL Server 2022.

DNS
Долгосрочные блокировки таблицы не поддерживаются во время операций с индексами. Во время главной фазы операций с индексами только блокировка с намерением совмещаемого доступа (IS) удерживается в исходной таблице. Это включает запросы или обновления применительно к обрабатываемой базовой таблице и индексам. В начале операции совмещаемая блокировка (S) удерживается на исходном объекте в течение очень короткого времени. Если создается некластеризованный индекс, в конце операции на короткое время выполняется совмещаемая блокировка (S) для исходного объекта. Если в режиме "сети" создается или удаляется кластеризованный индекс либо перестраивается кластеризованный или некластеризованный индекс, запрашивается блокировка SCH-M (изменение схемы). При создании индекса для временной локальной таблицы параметр ONLINE не может принимать значение ON.

Примечание.

При создании индекса в режиме "в сети" могут задаваться параметры low_priority_lock_wait. См. WAIT_AT_LOW_PRIORITY с операциями с индексами в сети.

ВЫКЛ.
Блокировки таблиц применяются во время выполнения операций с индексами. Блокировку изменения схемы (Sch-M) в таблице получает операция с индексами вне сети, которая создает, перестраивает или удаляет кластеризованный индекс либо перестраивает или удаляет некластеризованный индекс. Это предотвращает доступ к базовой таблице всех пользователей во время операции. Операция с индексами вне сети, создающая некластеризованный индекс, получает совмещаемую блокировку (S) в таблице. Это запрещает проводить обновления базовой таблицы, но разрешает проводить операции чтения, например инструкции SELECT.

Дополнительные сведения см. в статье Выполнение операции с индексами в сети.

Индексы, в том числе индексы глобальных временных таблиц, могут быть созданы при подключении к сети, за исключением следующего:

• XML-индекс
• Индекс локальной временной таблицы
• Исходные уникальные кластеризованные индексы представлений.
• Отключенные кластеризованные индексы.
• Индексы columnstore
• Кластеризованные индексы, если базовая таблица содержит типы данных LOB: image, ntext, text и пространственные типы данных.
• Столбцы varchar(max) и varbinary(max) не могут быть частью ключа индекса. В SQL Server (начиная с SQL Server 2012 (11.x)) и База данных SQL Azure, если таблица содержит столбцы varchar(max) или varbinary(max), кластеризованный индекс, содержащий другие столбцы, можно создать или перестроить с помощью этого ONLINE параметра.

Дополнительные сведения см. в разделе Об операциях с индексами в режиме "в сети".

RESUMABLE = { ON | OFF }

Область применения: SQL Server (начиная с SQL Server 2019 (15.x)) и База данных SQL Azure

Указывает, является ли операция с индексами в режиме "в сети" возобновляемой.

DNS
Операция с индексами является возобновляемой.

ВЫКЛ.
Операция с индексами является невозобновляемой.

MAX_DURATION = time [MINUTES] используется с RESUMABLE = ON (требуется ONLINE = ON)

Область применения: SQL Server (начиная с SQL Server 2019 (15.x)) и База данных SQL Azure

Указывает время (целочисленное значение минутах), в течение которого выполняется возобновляемая операция с индексами в сети до приостановки.

Внимание

Более подробные сведения об операциях с индексами, которые можно выполнить в сети, см. в разделе Рекомендации по операциям с индексами в сети.

Примечание.

Повторное перестроение индексов в Сети не поддерживается в индексах columnstore или отключенных индексах.

ALLOW_ROW_LOCKS = { ON | OFF }

Указывает, разрешена ли блокировка строк. Значение по умолчанию — ON.

DNS
Блокировки строк допустимы при доступе к индексу. Ядро СУБД определяет, когда используются блокировки строк.

ВЫКЛ.
Блокировки строк не используются.

ALLOW_PAGE_LOCKS = { ON | OFF }

Указывает, разрешена ли блокировка страниц. Значение по умолчанию — ON.

DNS
Блокировки страниц возможны при доступе к индексу. Ядро СУБД определяет, когда используются блокировки страниц.

ВЫКЛ.
Блокировки страниц не используются.

OPTIMIZE_FOR_SEQUENTIAL_KEY = { ON | OFF }

Область применения: SQL Server (начиная с SQL Server 2019 (15.x)) и База данных SQL Azure

Определяет, следует ли выполнять оптимизацию, связанную с состязанием при операциях вставки на последнюю страницу. Значение по умолчанию — OFF. См. подробнее раздел о последовательных ключах.

MAXDOP = max_degree_of_parallelism

Переопределяет параметр конфигурации max degree of parallelism на время выполнения операции с индексами. Дополнительные сведения см. в разделе Настройка параметра конфигурации сервера max degree of parallelism. MAXDOP можно использовать для ограничения числа процессоров, используемых при параллельном выполнении планов. Максимальное число процессоров — 64.

Параметр max_degree_of_parallelism может иметь одно из следующих значений:

1
Подавляет формирование параллельных планов.

>1
Ограничивает максимальное количество процессоров, используемых в параллельных операциях с индексами, заданным или меньшим числом в зависимости от текущей рабочей нагрузки системы.

0 (по умолчанию)
В зависимости от текущей рабочей нагрузки системы использует реальное или меньшее число процессоров.

Дополнительные сведения см. в статье Настройка параллельных операций с индексами.

Примечание.

Параллельные операции с индексами доступны не во всех выпусках Microsoft SQL Server. Список функций, поддерживаемых выпусками SQL Server, см. в выпусках и поддерживаемых функциях SQL Server 2022.

DATA_COMPRESSION

Задает режим сжатия данных для указанного индекса, номера секции или диапазона секций. Существуют следующие варианты выбора.

NONE
Индекс или заданные секции не сжимаются.

ROW
Для индекса или заданных секций производится сжатие строк.

СТРАНИЦА
Для индекса или заданных секций производится сжатие страниц.

Дополнительные сведения о сжатии см. в разделе Сжатие данных.

XML_COMPRESSION

Область применения: SQL Server 2022 (16.x) и более поздних версий, База данных SQL Azure и Управляемый экземпляр SQL Azure.

Задает параметр сжатия XML для указанного индекса, содержащего один или несколько столбцов с типом данных xml. Существуют следующие варианты выбора.

DNS
Для индекса или заданных секций производится сжатие XML.

ВЫКЛ.
Индекс или заданные секции не сжимаются.

ON PARTITIONS ( { <partition_number_expression> | <range> } [ ,...n ] )

Указывает разделы, к которым применяется параметр DATA_COMPRESSION или XML_COMPRESSION. Если индекс не секционирован, аргумент ON PARTITIONS приведет к возникновению ошибки. Если не указано предложение ON PARTITIONS, параметр DATA_COMPRESSION или XML_COMPRESSION применяется ко всем секциям секционированного индекса.

<partition_number_expression> можно указать одним из следующих способов.

• указав номер секции, например ON PARTITIONS (2);
• указав номера нескольких секций, разделив их запятыми, например ON PARTITIONS (1, 5);
• указав диапазоны секций и отдельные секции, например ON PARTITIONS (2, 4, 6 TO 8);

<range> можно указать в виде номеров секций, разделенных ключевым словом TO, например: ON PARTITIONS (6 TO 8).

Чтобы для разных секций задать разные типы сжатия данных, укажите параметр DATA_COMPRESSION несколько раз, например следующим образом:

REBUILD WITH
(
  DATA_COMPRESSION = NONE ON PARTITIONS (1),
  DATA_COMPRESSION = ROW ON PARTITIONS (2, 4, 6 TO 8),
  DATA_COMPRESSION = PAGE ON PARTITIONS (3, 5)
);

Параметр XML_COMPRESSION можно указывать несколько раз, например:

REBUILD WITH
(
  XML_COMPRESSION = OFF ON PARTITIONS (1),
  XML_COMPRESSION = ON ON PARTITIONS (2, 4, 6 TO 8),
  XML_COMPRESSION = OFF ON PARTITIONS (3, 5)
);

Замечания

Инструкция CREATE INDEX оптимизируется, как и любой другой запрос. Для уменьшения числа операций ввода-вывода обработчик запросов может вместо таблицы просматривать другой индекс. В некоторых ситуациях можно отказаться от операций сортировки. На многопроцессорных компьютерах инструкция CREATE INDEX, как и другие запросы, может использовать больше процессоров для операций просмотра и сортировки, связанных с созданием индекса. Дополнительные сведения см. в статье Настройка параллельных операций с индексами.

Возможно минимальное протоколирование операции CREATE INDEX, если модель восстановления базы данных настроена на массовый или простой режим.

Индексы могут создаваться для временной таблицы. При удалении таблицы или в конце сеанса такие индексы удаляются.

Кластеризованный индекс можно создать на основе табличной переменной при создании первичного ключа. После завершения выполнения запроса или окончания сеанса индекс уничтожается.

Индексы поддерживают расширенные свойства.

CREATE INDEX не поддерживается в Microsoft Fabric.

Кластеризованные индексы

Чтобы создать кластеризованный индекс для таблицы (кучи) или удалить и повторно создать существующий кластеризованный индекс, требуется дополнительная рабочая область в базе данных для сортировки и временного копирования данных исходной таблицы или существующего кластеризованного индекса. Дополнительные сведения о кластеризованных индексах см. в статьях Создание кластеризованных индексов и Руководство по архитектуре и разработке индексов SQL Server.

Некластеризованные индексы

Начиная с SQL Server 2016 (13.x) и в База данных SQL Azure, можно создать некластеризованный индекс в таблице, хранящейся в виде кластеризованного индекса columnstore. Если сначала создать некластеризованный индекс в таблице, сохраненной в виде кучи или кластеризованного индекса, индекс сохранится после дальнейшего преобразования таблицы в кластеризованный индекс columnstore. Кроме того, необязательно удалять некластеризованный индекс при перестройке кластеризованного индекса columnstore.

Ограничения

• Параметр FILESTREAM_ON является недопустимым при создании некластеризованного индекса в таблице, сохраненной в виде кластеризованного индекса columnstore.

Уникальные индексы

При наличии уникального индекса ядро СУБД проверяет наличие повторяющихся значений при каждом добавлении данных операциями вставки. Операции вставки, создающие повторяющиеся значения ключей, откатываются, а ядро СУБД отображает сообщение об ошибке. Это происходит даже в случае, если операция вставки изменяет несколько строк, а повторяющееся значение может появиться всего одно. Если делается попытка ввести данные, для которых существует уникальный индекс, и предложение IGNORE_DUP_KEY имеет значение ON, сбоем завершаются операции только с теми строками, где нарушается свойство уникальности индекса.

Секционированные индексы

Секционированные индексы создаются и поддерживаются так же, как и секционированные таблицы, но обрабатываются как отдельные объекты базы данных подобно обычным индексам. Можно создать секционированный индекс для несекционированной таблицы и несекционированный индекс для секционированной таблицы.

Если создается индекс для секционированной таблицы и не указывается файловая группа, в которую должен быть помещен индекс, индекс секционируется так же, как и базовая таблица. Дело в том, что по умолчанию индексы помещаются в те же файловые группы, что и их базовые таблицы, а в случае секционированной таблицы — в схему секционирования, использующую те же самые столбцы секционирования. Когда индекс использует ту же схему и столбец секционирования, что и таблица, индекс выравнивается с таблицей.

Предупреждение

Создание и перестройка невыровненных индексов для таблицы, количество секций в которой превышает 1000, возможны, но не поддерживаются. Это может привести к снижению производительности или чрезмерному потреблению памяти во время таких операций. Если количество секций превышает 1000, рекомендуется использовать только выровненные индексы.

При секционировании не уникального кластеризованного индекса ядро СУБД по умолчанию добавляет все столбцы секционирования в список кластеризованных ключей индекса, если он еще не указан.

Индексированные представления могут создаваться для секционированных таблиц таким же образом, как и индексы для таблиц. Дополнительные сведения о секционированных индексах см. в статьях Секционированные таблицы и индексы и Руководство по архитектуре и разработке индексов SQL Server.

В SQL Server статистика не создается путем сканирования всех строк в таблице при создании или перестроении секционированного индекса. Вместо этого оптимизатор запросов использует для создания статистики алгоритм выборки по умолчанию. Для получения статистики по секционированным индексам путем сканирования всех строк таблицы используйте инструкции CREATE STATISTICS или UPDATE STATISTICS с предложением FULLSCAN.

Отфильтрованные индексы

Отфильтрованный индекс является оптимизированным некластеризованным индексом, предназначенным для запросов, выбирающих небольшой процент строк таблицы. Чтобы проиндексировать часть данных таблицы, в нем используется предикат фильтра. Правильно составленный отфильтрованный индекс может увеличить скорость выполнения запроса, уменьшить стоимость хранения и обслуживания.

Обязательные параметры SET для отфильтрованных индексов

Параметры SET в столбце Required Value необходимы при возникновении любого из следующих условий.

• Создание отфильтрованного индекса.

• Операция INSERT, UPDATE, DELETE или MERGE изменяет данные в отфильтрованном индексе.

• Отфильтрованный индекс используется оптимизатором запросов для создания плана запроса.

  Параметры SET	Обязательное значение	Значение сервера по умолчанию	По умолчанию. Значение OLE DB и ODBC	По умолчанию. Значение DB-Library
  ANSI_NULLS	DNS	DNS	DNS	ВЫКЛ.
  ANSI_PADDING	DNS	DNS	DNS	ВЫКЛ.
  ANSI_WARNINGS*	DNS	DNS	DNS	ВЫКЛ.
  ARITHABORT	DNS	DNS	ВЫКЛ.	ВЫКЛ.
  CONCAT_NULL_YIELDS_NULL	DNS	DNS	DNS	ВЫКЛ.
  NUMERIC_ROUNDABORT	ВЫКЛ.	ВЫКЛ.	ВЫКЛ.	ВЫКЛ.
  QUOTED_IDENTIFIER	DNS	DNS	DNS	ВЫКЛ.

  • Если уровень совместимости базы данных равен 90 или более, при установке параметра ANSI_WARNINGS в состояние ON параметр ARITHABORT также устанавливается в состояние ON. Если уровень совместимости базы данных установлен в состояние 80 или более раннее, то параметр ARITHABORT необходимо явным образом установить в состояние ON.

Если параметры SET неверны, может произойти следующее.

• Отфильтрованный индекс не будет создан.
• Ядро СУБД создает ошибку и откатывает инструкции INSERT, UPDATE, DELETE или MERGE, изменяющие данные в индексе.
• Оптимизатор запросов не учитывает индекс в плане выполнения любой инструкции Transact-SQL.

Дополнительные сведения об отфильтрованных индексах см. в статьях Создание отфильтрованных индексов и Руководство по архитектуре и разработке индексов SQL Server.

Пространственные индексы

Сведения о пространственных индексах см. в описании CREATE SPATIAL INDEX и статье Общие сведения о пространственных индексах.

XML-индексы

Сведения об XML-индексах см. в описании CREATE XML INDEX и статье XML-индексы (SQL Server).

Размер ключа индекса

Максимальный размер ключа индекса составляет 900 байт для кластеризованного индекса и 1700 байт для некластеризованного индекса. (До Базы данных SQL и SQL Server 2016 (13.x) ограничение всегда составляло 900 байт.) Индексы в столбцах varchar, размер которых превышает максимальный, могут быть созданы, если в момент создания индекса объем существующих данных в столбцах не превышает максимальный, но последующие операции вставки или обновления, вызывающие превышение общего максимального размера, будут заканчиваться ошибкой. Ключ кластеризованного индекса не может включать в себя столбцы varchar, для которых существуют данные в единице размещения ROW_OVERFLOW_DATA. Если кластеризованный индекс создается для столбца типа varchar и существующие данные располагаются в единице размещения IN_ROW_DATA, то все последующие операции вставки или обновления для данного столбца, выталкивающие данные за пределы строки, будут завершаться ошибкой.

Некластеризованные индексы могут включать неключевые столбцы на конечном уровне индекса. Эти столбцы не учитываются ядро СУБД при вычислении размера ключа индекса. Дополнительные сведения см. в статьях Создание индексов с включенными столбцами и Руководство по архитектуре и разработке индексов SQL Server.

Примечание.

Если таблицы секционируются, если ключевые столбцы секционирования еще не присутствуют в не уникальном кластеризованном индексе, они добавляются в индекс ядро СУБД. Объединенный размер индексированных столбцов (без учета включенных столбцов) и любых добавленных столбцов секционирования в неуникальном кластеризованном индексе не может превышать 1800 байт.

Вычисляемые столбцы

Индексы могут создаваться в вычисляемых столбцах. Кроме того, вычисляемые столбцы могут иметь свойство PERSISTED. Это означает, что ядро СУБД сохраняет вычисляемые значения в таблице и обновляет их при обновлении любых других столбцов, от которых зависит вычисляемый столбец. Ядро СУБД использует эти сохраненные значения при создании индекса в столбце и при ссылке на индекс в запросе.

Для индексации вычисляемого столбца этот вычисляемый столбец должен быть детерминированным и точным. Если используется свойство PERSISTED, список типов индексируемых вычисляемых столбцов расширяется и включает следующее.

• Вычисляемые столбцы, основанные на Transact-SQL, функциях CLR и методах определяемых пользователем типов данных CLR, помеченных пользователем как детерминированные.
• Вычисляемые столбцы на основе выражений, детерминированных в соответствии с ядро СУБД, но неточными.

Для материализованных вычисляемых столбцов необходимо, чтобы следующие параметры SET имели значения, указанные выше в разделе Обязательные параметры SET для отфильтрованных индексов.

Ограничения UNIQUE или PRIMARY KEY могут содержать вычисляемый столбец, если он удовлетворяет всем условиям для индексирования. Вычисляемый столбец должен быть детерминированным и точным или детерминированным и сохраняемым. Дополнительные сведения о детерминизме см. в статье Детерминированные и недетерминированные функции.

Вычисляемые столбцы, производные от типов данных image, ntext, text, varchar(max), nvarchar(max), varbinary(max) и xml, могут индексироваться как ключевой или неключевой столбец, если тип данных вычисляемого столбца допускается в качестве ключевого или неключевого столбца индекса. Например, нельзя создать первичный XML-индекс для вычисляемого столбца XML. Если размер ключа индекса превышает 900 байт, выдается предупреждение.

Создание индекса на вычисляемом столбце может привести к ошибке в операциях вставки или обновления, которые до этого успешно выполнялись. Такое неуспешное завершение возможно, если вычисляемый столбец вызывает арифметическую ошибку. Например, вычисляемый столбец c в следующей таблице приводит к арифметической ошибке, но инструкция INSERT работает нормально.

CREATE TABLE t1 (a INT, b INT, c AS a/b);
INSERT INTO t1 VALUES (1, 0);

Если же после создания таблицы создать индекс на вычисляемом столбце c, та же инструкция INSERT будет заканчиваться ошибкой.

CREATE TABLE t1 (a INT, b INT, c AS a/b);
CREATE UNIQUE CLUSTERED INDEX Idx1 ON t1(c);
INSERT INTO t1 VALUES (1, 0);

Дополнительные сведения см. в разделе Индексы вычисляемых столбцов.

Включенные столбцы в индексах

Неключевые столбцы, называемые "включенными столбцами", могут добавляться на конечный уровень некластеризованного индекса для повышения производительности запроса благодаря тому, что индекс включает все необходимые данные для запроса. Т. е. все столбцы, указанные в запросе, включаются в индекс в качестве ключевых или неключевых столбцов. Таким образом, оптимизатор запросов может найти все необходимые данные путем просмотра индекса, не обращаясь к данным таблицы или кластеризованного индекса. Дополнительные сведения см. в статьях Создание индексов с включенными столбцами и Руководство по архитектуре и разработке индексов SQL Server.

Установка параметров индекса

SQL Server 2005 (9.x) представил новые параметры индекса, а также изменяет способ указания параметров. Для обратной совместимости синтаксиса аргумент WITH option_name эквивалентен WITH (option_name = ON). Устанавливая параметры индекса, необходимо соблюдать следующие правила.

• Новые параметры индекса могут быть заданы только с помощью аргумента WITH (<option_name> = <ON | OFF>).
• Нельзя задавать параметры с помощью нового синтаксиса и совместимого старого в одной и той же инструкции. Например, указание WITH (DROP_EXISTING, ONLINE = ON) приводит к сбою инструкции.
• При создании XML-индекса параметры должны указываться с помощью аргумента WITH (<option_name> = <ON | OFF>).

DROP_EXISTING, предложение

Предложение DROP_EXISTING может использоваться для перестроения индекса, добавления или удаления столбцов, изменения параметров, изменения порядка сортировки столбцов, а также изменения схемы секционирования или файловой группы.

Если индекс принудительно налагает ограничение PRIMARY KEY или UNIQUE и его определение никак не меняется, он удаляется и создается вновь с сохранением существующих ограничений. Но если изменить определение индекса, инструкция вызовет ошибку. Чтобы изменить ограничение PRIMARY KEY или UNIQUE, удалите ограничение и добавьте ограничение вместе с новым определением.

Предложение DROP_EXISTING повышает производительность, если повторно создается кластеризованный индекс с тем же самым или другим набором ключей в таблице, имеющей также некластеризованные индексы. Предложение DROP_EXISTING заменяет удаление старого кластеризованного индекса с помощью инструкции DROP INDEX и последующее создание нового кластеризованного индекса с помощью инструкции CREATE INDEX. Некластеризованные индексы перестраиваются один раз, а после этого только в случае, если меняется определение индекса. Предложение DROP_EXISTING не перестраивает некластеризованные индексы, если определение индекса содержит то же самое имя индекса, ключевые столбцы, столбцы секционирования, атрибут уникальности и порядок сортировки, что и исходный индекс.

Независимо от того, перестраиваются ли некластеризованные индексы, они всегда остаются в своих исходных файловых группах или схемах секционирования и используют исходные функции секционирования. Если кластеризованный индекс перестраивается в другой файловой группе или схеме секционирования, некластеризованные индексы не перемещаются вместе с кластеризованным индексом. Поэтому даже если некластеризованные индексы раньше были выровнены по кластеризованному, теперь это может быть не так. Дополнительные сведения о выравнивании секционированных индексов см. в разделе Секционированные таблицы и индексы.

Предложение DROP_EXISTING не сортирует данные заново, если те же ключевые столбцы индекса используются в том же порядке с тем же порядком сортировки по возрастанию или убыванию, за исключением случаев, когда инструкция индекса задает некластеризованный индекс и параметр ONLINE равен OFF. Если кластеризованный индекс отключен, операция CREATE INDEX WITH DROP_EXISTING должна выполняться с параметром ONLINE в значении OFF. Если некластеризованный индекс отключен и не связан с отключенным кластеризованным индексом, операция CREATE INDEX WITH DROP_EXISTING может выполняться с параметром ONLINE в значении OFF или ON.

Примечание.

Если индексы с 128 экстентами или более удаляются или перестраиваются, ядро СУБД откладывает фактическое размещение сделки страницы и связанные с ними блокировки до тех пор, пока транзакция не будет зафиксирована.

ONLINE, параметр

Следующие правила применяются к операциям с индексами в режиме в сети.

• Во время выполнения операций с индексами в сети базовая таблица не может изменяться, усекаться или удаляться.
• Для операций с индексами требуется дополнительное временное место на диске.
• Обработка индексов в сети может выполняться для секционированных индексов, содержащих материализованные вычисляемые столбцы или включенные столбцы.
• Параметр аргумента low_priority_lock_wait позволяет решить, каким образом будет продолжена операция с индексами при Sch-M-блокировке.

Дополнительные сведения см. в статье Выполнение операции с индексами в сети.

Ресурсы

Для операции создания возобновляемого индекса в сети необходимы следующие ресурсы.

• Дополнительное место для хранения создаваемого индекса, включая время, когда индекс будет приостановлен.
• Дополнительная пропускная способность для журналов на период сортировки. Общее потребление пространства для журналов у возобновляемого индекса меньше по сравнению с обычной операцией создания индекса в сети. Кроме того, эта операция поддерживает усечение журнала во время выполнения.
• Состояние DDL, запрещающее изменения DDL.
• Очистка фантомных записей блокируется для встроенных индексов на весь период операции, в том числе пока она приостановлена.

Существующие функциональные ограничения

Для возобновляемых операций создания индексов отключены следующие функциональные возможности.

• После приостановки возобновляемой операции создания индекса в сети нельзя изменить исходное значение MAXDOP.

• Создание индекса, который содержит следующее:

  • вычисляемые столбцы или столбцы TIMESTAMP в качестве ключевых столбцов;
  • столбец LOB в качестве включенного столбца для создания возобновляемого индекса.
  • Фильтруемый индекс

Возобновляемые операции с индексами

Область применения: SQL Server (начиная с SQL Server 2019 (15.x)) и База данных SQL Azure

Следующие правила применяются к операциям с возобновляемыми индексами.

• Операция создания индексов в подключенном режиме указывается как возобновляемая с помощью параметра RESUMABLE = ON.
• Параметр RESUMABLE не сохраняется в метаданных для указанного индекса и применяется только на время выполнения текущей инструкции DDL. Таким образом, для включения возобновляемости предложение RESUMABLE = ON должно быть указано явным образом.
• Параметр MAX_DURATION поддерживается только для RESUMABLE = ON.
• Параметр MAX_DURATION при включенном параметре RESUMABLE задает интервал времени для создания индекса. По истечении этого времени операция создания индекса приостанавливается или завершается. Пользователь решает, когда можно будет возобновить создание приостановленного индекса. Значение time в минутах для MAX_DURATION должно быть больше 0 минут и меньше или равно 1 неделе (7 * 24 * 60 = 10 080 минут). Длинная пауза в операции с индексами может повлиять на производительность DML в конкретной таблице, а также на емкость диска базы данных, поскольку они оба индексируют исходное и только что созданное требуемое место на диске и должны быть обновлены во время операций DML. Если параметр MAX_DURATION пропускается, операция с индексами будет продолжаться вплоть до ее завершения или до момента возникновения сбоя.
• Чтобы немедленно приостановить операцию создания индекса, можно остановить текущую команду сочетанием клавиш CTRL+C либо выполнить команду ALTER INDEX PAUSE или команду KILL <session_id>. Приостановленную команду можно возобновить командой ALTER INDEX.
• Повторное выполнение исходной инструкции CREATE INDEX для возобновляемого индекса автоматически возобновляет приостановленную операцию создания индекса.
• Параметр SORT_IN_TEMPDB = ON не поддерживается для возобновляемых индексов.
• Команду DDL с параметром RESUMABLE = ON невозможно выполнить внутри явной транзакции (она не может быть частью блока TRAN ... COMMIT).
• Чтобы возобновить или прервать создание или перестроение индекса, используйте синтаксис ALTER INDEX T-SQL.
• Отключенные индексы не поддерживаются.

Примечание.

Команда DDL выполняется вплоть до завершения, приостанавливается или завершается ошибкой. Если команда приостанавливается, возникнет ошибка, указывающая на приостановку операции и невозможность завершения создания индекса. Дополнительные сведения о текущем состоянии индекса можно получить из sys.index_resumable_operations. Как и в случае выше, при сбое также будет выведено сообщение об ошибке.

Чтобы указать, что создание индекса выполняется как возобновляемая операция, и проверить текущее состояние выполнения, см. статью index_resumable_operations (Transact-SQL).

WAIT_AT_LOW_PRIORITY с операциями с индексами в режиме "в сети"

Применяется к: этот синтаксис применяется только к CREATE INDEX SQL Server 2022 (16.x), База данных SQL Azure и только Управляемый экземпляр SQL Azure. Для ALTER INDEXэтого синтаксиса применяется к SQL Server (начиная с SQL Server 2014 (12.x)) и База данных SQL Azure. Подробные сведения см. в статье ALTER INDEX (Transact-SQL).

Синтаксис low_priority_lock_wait позволяет указать поведение WAIT_AT_LOW_PRIORITY. WAIT_AT_LOW_PRIORITY может использоваться только с ONLINE=ON.

Параметр WAIT_AT_LOW_PRIORITY позволяет администратору базы данных управлять блокировками Sch-S и Sch-M, необходимыми для создания индекса в режиме "в сети". Доступны 3 варианта. Во всех 3 случаях, если во время ожидания MAX_DURATION = n [minutes] нет блокирующих действий, то перестроение индекса в режиме "в сети" выполняется немедленно и без ожидания завершения инструкции DDL.

Значение WAIT_AT_LOW_PRIORITY указывает, что операция создания индекса в режиме "в сети" будет ожидать блокировки с низким приоритетом, позволяя выполняться другим операциям, пока операция построения индекса в режиме "в сети" находится в состоянии ожидания. Пропуск параметра WAIT AT LOW PRIORITY эквивалентен WAIT_AT_LOW_PRIORITY (MAX_DURATION = 0 minutes, ABORT_AFTER_WAIT = NONE).

MAX_DURATION = time [MINUTES]

Время ожидания (целочисленное значение, указанное в минутах), в течение которого блокировки для операции создания индекса в режиме "в сети" будут ожидать с низким приоритетом при выполнении команды DDL. Если операция заблокирована в течение времени MAX_DURATION, будет выполнено указанное действие ABORT_AFTER_WAIT. Время MAX_DURATION всегда указывается в минутах, и слово MINUTES можно опустить.

ABORT_AFTER_WAIT = [NONE | SELF | BLOCKERS } ]

NONE — продолжить ожидание блокировки с обычным приоритетом.

Прекратить операцию DDL по созданию индекса в режиме "в сети", выполняемую в данный момент, без какого-либо действия. Параметр SELF не может использоваться с параметром MAX_DURATION, равным нулю.

BLOCKERS — остановка всех пользовательских транзакций, которые в данный момент блокируют операцию DDL по перестроению индекса в режиме "в сети", чтобы можно было продолжить данную операцию. Параметр BLOCKERS требует, чтобы учетная запись имела разрешение ALTER ANY CONNECTION.

Параметры блокировок строк и страниц

Когда присвоены значения ALLOW_ROW_LOCKS = ON и ALLOW_PAGE_LOCK = ON, при доступе к индексу допустимы блокировки на уровне строк, страниц и таблиц. Ядро СУБД выбирает соответствующую блокировку и может передавать блокировку из строки или блокировки страницы на блокировку таблицы.

Если присвоены значения ALLOW_ROW_LOCKS = OFF и ALLOW_PAGE_LOCK = OFF, при доступе к индексу допустима только блокировка на уровне таблиц.

Последовательные ключи

Область применения: SQL Server (начиная с SQL Server 2019 (15.x)) и База данных SQL Azure

Состязание операций вставки на последнюю страницу — это распространенная проблема, влияющая на производительность. Она возникает, когда множество параллельных запросов пытается вставить строки в индекс с последовательным ключом. Индекс считается последовательным, если ведущий ключевой столбец содержит значения, которые всегда увеличиваются (или уменьшаются), например столбец идентификаторов или даты, в котором по умолчанию используется текущее значение даты и времени. Так как ключи вставляются последовательно, все новые строки будут вставляться в конце структуры индекса, т. е. на одной и той же странице. Это приводит к состязанию за страницы в памяти. В этой ситуации несколько потоков ожидают PAGELATCH_EX для указанной страницы.

Параметр индекса OPTIMIZE_FOR_SEQUENTIAL_KEY включает оптимизацию в ядре СУБД, что позволяет повысить пропускную способность для операций вставки с высокой степенью параллелизма в индекс. Этот параметр предназначен для индексов с последовательным ключом, из-за которого возникает состояние состязания при операциях вставки на последнюю страницу. Но его также можно применять для индексов с критическими участками в других областях структуры индекса в виде сбалансированного дерева.

Примечание.

В документации термин B-tree обычно используется в ссылке на индексы. В индексах rowstore ядро СУБД реализует дерево B+. Это не относится к индексам columnstore или индексам в таблицах, оптимизированных для памяти. Дополнительные сведения см. в руководстве по архитектуре и проектированию индексов SQL Sql Server и Azure.

Просмотр сведений об индексах

Получить данные об индексах можно с помощью представлений каталогов, системных функций и системных хранимых процедур.

Сжатие данных

Сжатие данных описывается в разделе Сжатие данных. Необходимо учесть следующие основные моменты.

• С помощью сжатия можно хранить больше строк в странице, максимальный размер строки при этом не изменяется.
• Неконечные страницы индекса не сжаты на уровне страниц, но могут быть сжаты на уровне строк.
• У каждого некластеризованного индекса индивидуальные настройки сжатия, которые не наследуются от базовой таблицы.
• При создании кластеризованного индекса в куче кластеризованный индекс наследует состояние сжатия кучи, если не указано другое состояние сжатия.

На секционированные индексы налагаются следующие ограничения.

• Если в таблице есть невыровненные индексы, настройку сжатия для отдельной секции изменить нельзя.
• Синтаксис ALTER INDEX <index> ... REBUILD PARTITION ... производит перестроение указанной секции индекса.
• Синтаксис ALTER INDEX <index> ... REBUILD WITH ... производит перестроение всех секций индекса.

Оценить состояние сжатия таблицы, индекса или секции можно с помощью хранимой процедуры sp_estimate_data_compression_savings.

Сжатие XML

Область применения: SQL Server 2022 (16.x) и более поздних версий, База данных SQL Azure и Управляемый экземпляр SQL Azure.

Многие из соображений по сжатию данных применимы и к сжатию XML. Необходимо всегда принимать во внимание следующие соображения.

• Если указан список секций, для каждой отдельной секции можно установить сжатие XML. Если список секций не указан, сжатие XML устанавливается для всех секций. При создании индекса или таблицы сжатие XML является отключенным, если не было указано другое. При изменении таблицы сохраняется существующее сжатие, если не было указано иное.
• При указании списка секций или секции, выходящей за пределы диапазона, выдается ошибка.
• При создании кластеризованного индекса в куче кластеризованный индекс наследует состояние сжатия XML кучи, если не указан другой параметр сжатия.
• Чтобы изменить параметры сжатия XML кучи, необходимо перестроить все некластеризованные индексы в таблице. Это обеспечивает наличие в них указателей на новые расположения в куче.
• Включить или отключить сжатие XML можно в оперативном режиме или в режиме вне сети. Включение сжатия для кучи является однопоточным для операции в сети.
• Чтобы определить состояние сжатия XML секций в секционированной таблице, выполните запрос столбца xml_compression из представления каталога sys.partitions.

Разрешения

Необходимо разрешение ALTER для таблицы или представления или членство в предопределенных ролях базы данных db_ddladmin.

ограничения

В Azure Synapse Analytics и Система платформы аналитики (PDW) нельзя создать:

• кластеризованный или некластеризованный индекс rowstore в таблице хранилища данных, если индекс columnstore уже существует. Это поведение отличается от SMP SQL Server, что позволяет использовать индексы rowstore и columnstore в одной таблице.
• Нельзя создать индекс для представления.

Метаданные

Чтобы просмотреть сведения о существующих индексах, можно выполнить запрос к представлению каталога sys.indexes.

Заметки о версии

База данных SQL не поддерживает параметры файловой группы и файлового потока.

Примеры: все версии. Используется база данных AdventureWorks

А. Создание простого некластеризованного индекса rowstore

В следующем примере создается некластеризованный индекс для столбца VendorID таблицы Purchasing.ProductVendor.

CREATE INDEX IX_VendorID ON ProductVendor (VendorID);
CREATE INDEX IX_VendorID ON dbo.ProductVendor (VendorID DESC, Name ASC, Address DESC);
CREATE INDEX IX_VendorID ON Purchasing..ProductVendor (VendorID);

B. Создание простого некластеризованного составного индекса rowstore

В следующем примере создается некластеризованный составной индекс в столбцах SalesQuota и SalesYTD таблицы Sales.SalesPerson.

CREATE NONCLUSTERED INDEX IX_SalesPerson_SalesQuota_SalesYTD ON Sales.SalesPerson (SalesQuota, SalesYTD);

В. Создание индекса в таблице из другой базы данных

В следующем примере создается кластеризованный индекс для столбца VendorID таблицы ProductVendor в базе данных Purchasing.

CREATE CLUSTERED INDEX IX_ProductVendor_VendorID ON Purchasing..ProductVendor (VendorID);

D. Добавление столбца в индекс

В следующем примере создается индекс IX_FF с двумя столбцами из таблицы dbo.FactFinance. Следующая инструкция перестраивает индекс с еще одним столбцом и сохраняет существующее имя.

CREATE INDEX IX_FF ON dbo.FactFinance (FinanceKey ASC, DateKey ASC);

-- Rebuild and add the OrganizationKey
CREATE INDEX IX_FF ON dbo.FactFinance (FinanceKey, DateKey, OrganizationKey DESC)
  WITH (DROP_EXISTING = ON);

Примеры: SQL Server, база данных SQL Azure

Е. Создание уникального некластеризованного индекса

В следующем примере создается уникальный некластеризованный индекс в столбце Name таблицы Production.UnitMeasure в базе данных AdventureWorks2022. Индекс требует уникальности данных, вставляемых в столбец Name.

CREATE UNIQUE INDEX AK_UnitMeasure_Name
  ON Production.UnitMeasure(Name);

Следующий запрос проверяет ограничение уникальности данных при попытке вставить строку с тем же значением, что и в уже существующей строке.

-- Verify the existing value.
SELECT Name FROM Production.UnitMeasure WHERE Name = N'Ounces';
GO

INSERT INTO Production.UnitMeasure (UnitMeasureCode, Name, ModifiedDate)
  VALUES ('OC', 'Ounces', GETDATE());

В результате выдается сообщение об ошибке:

Server: Msg 2601, Level 14, State 1, Line 1
Cannot insert duplicate key row in object 'UnitMeasure' with unique index 'AK_UnitMeasure_Name'. The statement has been terminated.

F. Использование параметра IGNORE_DUP_KEY

В следующем примере демонстрируется влияние параметра IGNORE_DUP_KEY со значениями ON и OFF на операцию вставки нескольких строк во временную таблицу. В таблицу #Test вставляется одна строка, которая намеренно приведет к появлению повторяющихся значений при выполнении второй многострочной операции вставки INSERT. Счетчик строк таблицы возвращает количество вставленных строк.

CREATE TABLE #Test (C1 NVARCHAR(10), C2 NVARCHAR(50), C3 DATETIME);
GO

CREATE UNIQUE INDEX AK_Index ON #Test (C2)
  WITH (IGNORE_DUP_KEY = ON);
GO

INSERT INTO #Test VALUES (N'OC', N'Ounces', GETDATE());
INSERT INTO #Test SELECT * FROM Production.UnitMeasure;
GO

SELECT COUNT(*) AS [Number of rows] FROM #Test;
GO

DROP TABLE #Test;
GO

Ниже приведены результаты второй инструкции INSERT.

Server: Msg 3604, Level 16, State 1, Line 5 Duplicate key was ignored.

Number of rows
--------------
38

Обратите внимание, что строки из таблицы Production.UnitMeasure, не нарушающие ограничение уникальности, были успешно вставлены. Было выдано предупреждение, и строка с повторяющимся значением не была вставлена, но отката всей транзакции не произошло.

Те же инструкции выполняются вновь, но теперь с аргументом IGNORE_DUP_KEY, равным OFF.

CREATE TABLE #Test (C1 NVARCHAR(10), C2 NVARCHAR(50), C3 DATETIME);
GO

CREATE UNIQUE INDEX AK_Index ON #Test (C2)
  WITH (IGNORE_DUP_KEY = OFF);
GO

INSERT INTO #Test VALUES (N'OC', N'Ounces', GETDATE());
INSERT INTO #Test SELECT * FROM Production.UnitMeasure;
GO

SELECT COUNT(*) AS [Number of rows] FROM #Test;
GO

DROP TABLE #Test;
GO

Ниже приведены результаты второй инструкции INSERT.

Server: Msg 2601, Level 14, State 1, Line 5
Cannot insert duplicate key row in object '#Test' with unique index
'AK_Index'. The statement has been terminated.

Number of rows
--------------
1

Обратите внимание, что ни одна из строк таблицы Production.UnitMeasure не была вставлена, хотя ограничение индекса UNIQUE было нарушено только одной строкой.

G. Использование предложения DROP_EXISTING для удаления и повторного создания индекса

В следующем примере удаляется и создается повторно существующий индекс для столбца ProductID таблицы Production.WorkOrder в базе данных AdventureWorks2022 с использованием параметра DROP_EXISTING. Указываются также параметры FILLFACTOR и PAD_INDEX.

CREATE NONCLUSTERED INDEX IX_WorkOrder_ProductID
  ON Production.WorkOrder(ProductID)
    WITH (FILLFACTOR = 80,
      PAD_INDEX = ON,
      DROP_EXISTING = ON);
GO

H. Создание индекса для представления

В следующем примере создаются представление и индекс этого представления. Включено два запроса, использующих созданное индексированное представление.

-- Set the options to support indexed views
SET NUMERIC_ROUNDABORT OFF;
SET ANSI_PADDING, ANSI_WARNINGS, CONCAT_NULL_YIELDS_NULL, ARITHABORT,
  QUOTED_IDENTIFIER, ANSI_NULLS ON;
GO

-- Create view with schemabinding
IF OBJECT_ID ('Sales.vOrders', 'view') IS NOT NULL
  DROP VIEW Sales.vOrders;
GO

CREATE VIEW Sales.vOrders
  WITH SCHEMABINDING
AS
  SELECT SUM(UnitPrice * OrderQty * (1.00 - UnitPriceDiscount)) AS Revenue,
    OrderDate, ProductID, COUNT_BIG(*) AS COUNT
  FROM Sales.SalesOrderDetail AS od, Sales.SalesOrderHeader AS o
  WHERE od.SalesOrderID = o.SalesOrderID
  GROUP BY OrderDate, ProductID;
GO

-- Create an index on the view
CREATE UNIQUE CLUSTERED INDEX IDX_V1
  ON Sales.vOrders (OrderDate, ProductID);
GO

-- This query can use the indexed view even though the view is
-- not specified in the FROM clause.
SELECT SUM(UnitPrice * OrderQty * (1.00 - UnitPriceDiscount)) AS Rev,
  OrderDate, ProductID
FROM Sales.SalesOrderDetail AS od
  JOIN Sales.SalesOrderHeader AS o ON od.SalesOrderID = o.SalesOrderID
    AND ProductID BETWEEN 700 AND 800
    AND OrderDate >= CONVERT(DATETIME, '05/01/2002', 101)
GROUP BY OrderDate, ProductID
ORDER BY Rev DESC;
GO

-- This query can use the above indexed view
SELECT OrderDate, SUM(UnitPrice * OrderQty * (1.00 - UnitPriceDiscount)) AS Rev
FROM Sales.SalesOrderDetail AS od
  JOIN Sales.SalesOrderHeader AS o ON od.SalesOrderID = o.SalesOrderID
    AND DATEPART(mm, OrderDate) = 3
  AND DATEPART(yy, OrderDate) = 2002
GROUP BY OrderDate
ORDER BY OrderDate ASC;
GO

I. Создание индекса с включенными (неключевыми) столбцами

В следующем примере создается некластеризованный индекс с одним ключевым столбцом (PostalCode) и четырьмя неключевыми столбцами (AddressLine1, AddressLine2, City, StateProvinceID). Далее следует запрос, все данные для которого есть в индексе. Чтобы отобразить индекс, выбранный оптимизатором запросов, в меню "Запрос " в СРЕДЕ SQL Server Management Studio выберите "Отобразить фактический план выполнения" перед выполнением запроса.

CREATE NONCLUSTERED INDEX IX_Address_PostalCode
  ON Person.Address (PostalCode)
  INCLUDE (AddressLine1, AddressLine2, City, StateProvinceID);
GO

SELECT AddressLine1, AddressLine2, City, StateProvinceID, PostalCode
FROM Person.Address
WHERE PostalCode BETWEEN N'98000' and N'99999';
GO

J. Создание секционированного индекса

В следующем примере создается некластеризованный секционированный индекс для TransactionsPS1, существующей схемы секционирования в базе данных AdventureWorks2022. В данном примере подразумевается, что образец секционированного индекса установлен.

CREATE NONCLUSTERED INDEX IX_TransactionHistory_ReferenceOrderID
  ON Production.TransactionHistory (ReferenceOrderID)
  ON TransactionsPS1 (TransactionDate);
GO

K. Создание отфильтрованного индекса

В следующем примере создается фильтрованный индекс для таблицы Production.BillOfMaterials в базе данных AdventureWorks2022. Предикат фильтра может включать столбцы, не являющиеся ключевыми в отфильтрованном индексе. Предикат в примере выбирает только те строки, где EndDate не равно NULL.

CREATE NONCLUSTERED INDEX "FIBillOfMaterialsWithEndDate"
  ON Production.BillOfMaterials (ComponentID, StartDate)
  WHERE EndDate IS NOT NULL;

L. Создание сжатого индекса

Следующий пример демонстрирует создание индекса для несекционированной таблицы с помощью сжатия строк.

CREATE NONCLUSTERED INDEX IX_INDEX_1
  ON T1 (C2)
  WITH (DATA_COMPRESSION = ROW);
GO

Следующий пример демонстрирует создание индекса для секционированной таблицы с помощью сжатия строк во всех секциях индекса.

CREATE CLUSTERED INDEX IX_PartTab2Col1
  ON PartitionTable1 (Col1)
  WITH (DATA_COMPRESSION = ROW);
GO

Следующий пример демонстрирует создание индекса для секционированной таблицы с помощью сжатия страниц для секции 1 индекса и сжатия строк для секций индекса со 2 по 4.

CREATE CLUSTERED INDEX IX_PartTab2Col1
  ON PartitionTable1 (Col1)
  WITH (
    DATA_COMPRESSION = PAGE ON PARTITIONS(1),
    DATA_COMPRESSION = ROW ON PARTITIONS (2 TO 4)
  );
GO

M. Создание индекса с сжатием XML

Область применения: SQL Server 2022 (16.x) и более поздних версий, База данных SQL Azure и Управляемый экземпляр SQL Azure.

Следующий пример демонстрирует создание индекса для несекционированной таблицы с использованием сжатия XML. По крайней мере один столбец в индексе должен иметь тип данных xml.

CREATE NONCLUSTERED INDEX IX_INDEX_1
  ON T1 (C2)
  WITH (XML_COMPRESSION = ON);
GO

Следующий пример демонстрирует создание индекса для секционированной таблицы с использованием сжатия XML во всех секциях индекса.

CREATE CLUSTERED INDEX IX_PartTab2Col1
  ON PartitionTable1 (Col1)
  WITH (XML_COMPRESSION = ON);
GO

N. Создание, возобновление, приостановка и прерывание операций с возобновляемыми индексами

Область применения: SQL Server (начиная с SQL Server 2019 (15.x)) и База данных SQL Azure

-- Execute a resumable online index create statement with MAXDOP=1
CREATE INDEX test_idx1 ON test_table (col1) WITH (ONLINE = ON, MAXDOP = 1, RESUMABLE = ON);

-- Executing the same command again (see above) after an index operation was paused, resumes automatically the index create operation.

-- Execute a resumable online index creates operation with MAX_DURATION set to 240 minutes. After the time expires, the resumable index create operation is paused.
CREATE INDEX test_idx2 ON test_table (col2) WITH (ONLINE = ON, RESUMABLE = ON, MAX_DURATION = 240);

-- Pause a running resumable online index creation
ALTER INDEX test_idx1 ON test_table PAUSE;
ALTER INDEX test_idx2 ON test_table PAUSE;

-- Resume a paused online index creation
ALTER INDEX test_idx1 ON test_table RESUME;
ALTER INDEX test_idx2 ON test_table RESUME;

-- Abort resumable index create operation which is running or paused
ALTER INDEX test_idx1 ON test_table ABORT;
ALTER INDEX test_idx2 ON test_table ABORT;

O. CREATE INDEX с другими параметрами блокировки с низким приоритетом

В следующих примерах используется параметр WAIT_AT_LOW_PRIORITY для указания различных стратегий для работы с блокировкой.

--Kill this session after waiting 5 minutes
CREATE CLUSTERED INDEX idx_1 ON dbo.T2 (a) WITH (ONLINE = ON (WAIT_AT_LOW_PRIORITY (MAX_DURATION = 5 MINUTES, ABORT_AFTER_WAIT = SELF)));
GO

--Kill blocker sessions
CREATE CLUSTERED INDEX idx_1 ON dbo.T2 (a) WITH (ONLINE = ON (WAIT_AT_LOW_PRIORITY (MAX_DURATION = 5 MINUTES, ABORT_AFTER_WAIT = BLOCKERS)));
GO

В следующем примере используется параметр RESUMABLE и указывается два значения MAX_DURATION. Первое применяется к параметру ABORT_AFTER_WAIT, второе — к параметру RESUMABLE.

--With resumable option; default locking behavior 
CREATE CLUSTERED INDEX idx_1 ON dbo.T2 (a) WITH (ONLINE = ON (WAIT_AT_LOW_PRIORITY (MAX_DURATION = 5 MINUTES, ABORT_AFTER_WAIT = NONE)), RESUMABLE = ON, MAX_DURATION = 240 MINUTES);

Примеры: Azure Synapse Analytics и система платформы аналитики (PDW)

P. Основной синтаксис

Создание, возобновление, приостановка и прерывание операций с возобновляемыми индексами

Область применения: SQL Server (начиная с SQL Server 2019 (15.x)) и База данных SQL Azure

-- Execute a resumable online index create statement with MAXDOP=1
CREATE INDEX test_idx ON test_table WITH (ONLINE = ON, MAXDOP = 1, RESUMABLE = ON);

-- Executing the same command again (see above) after an index operation was paused, resumes automatically the index create operation.

-- Execute a resumable online index creates operation with MAX_DURATION set to 240 minutes. After the time expires, the resumable index create operation is paused.
CREATE INDEX test_idx ON test_table WITH (ONLINE = ON, RESUMABLE = ON, MAX_DURATION = 240);

-- Pause a running resumable online index creation
ALTER INDEX test_idx ON test_table PAUSE;

-- Resume a paused online index creation
ALTER INDEX test_idx ON test_table RESUME;

-- Abort resumable index create operation which is running or paused
ALTER INDEX test_idx ON test_table ABORT;

В. Создание некластеризованного индекса для таблицы в текущей базе данных

В приведенном ниже примере создается некластеризованный индекс по столбцу VendorID таблицы ProductVendor.

CREATE INDEX IX_ProductVendor_VendorID
  ON ProductVendor (VendorID);

R. Создание индекса для таблицы из другой базы данных

В приведенном ниже примере создается некластеризованный индекс по столбцу VendorID таблицы ProductVendor в базе данных Purchasing.

CREATE CLUSTERED INDEX IX_ProductVendor_VendorID
  ON Purchasing..ProductVendor (VendorID);

S. Создание кластеризованного индекса для таблицы

В следующем примере создается упорядоченный кластеризованный индекс на столбцах c1 и c2 таблицы T1 в базе данных MyDB.

CREATE CLUSTERED COLUMNSTORE INDEX MyOrderedCCI ON MyDB.dbo.T1 
ORDER (c1, c2);

T. Преобразование кластеризованного индекса columnstore в упорядоченный кластеризованный индекс таблицы

В следующем примере существующий кластеризованный индекс columnstore преобразуется в упорядоченный кластеризованный индекс columnstore с именем MyOrderedCCI для столбцов c1 и c2 таблицы T2 в базе данных MyDB.

CREATE CLUSTERED COLUMNSTORE INDEX MyOrderedCCI ON MyDB.dbo.T2
ORDER (c1, c2)
WITH (DROP_EXISTING = ON);

См. также

• Руководство по архитектуре и разработке индексов SQL Server
• Выполнение операций с индексами в оперативном режиме
• Индексы и инструкция ALTER TABLE
• ALTER INDEX
• CREATE PARTITION FUNCTION
• CREATE PARTITION SCHEME
• CREATE SPATIAL INDEX
• CREATE STATISTICS
• CREATE TABLE
• CREATE XML INDEX
• Data Types
• DBCC SHOW_STATISTICS
• DROP INDEX
• XML-индексы (SQL Server)
• sys.indexes
• sys.index_columns
• sys.xml_indexes
• EVENTDATA