Sdílet prostřednictvím


CREATE INDEX (Transact-SQL)

platí pro:SQL ServerAzure SQL Databaseazure SQL Managed InstanceAzure Synapse AnalyticsPlatform Platform System (PDW)

Vytvoří relační index v tabulce nebo zobrazení. Označuje se také jako index rowstore, protože se jedná o clusterovaný nebo neclusterovaný index B-tree. Index rowstore můžete vytvořit dříve, než budou v tabulce data. Pomocí indexu rowstore můžete zlepšit výkon dotazů, zejména pokud dotazy vybírají z konkrétních sloupců nebo vyžadují řazení hodnot v určitém pořadí.

Poznámka

Dokumentace používá termín B-tree obecně v odkazu na indexy. V indexech rowstore databázový stroj implementuje strom B+. To neplatí pro indexy columnstore ani indexy v tabulkách optimalizovaných pro paměť. Další informace najdete v SQL Serveru a architektuře indexu Azure SQL a průvodci návrhem.

Azure Synapse Analytics a systém PDW (Platform System) v současné době nepodporují jedinečná omezení. Všechny příklady odkazující na jedinečná omezení se vztahují pouze na SQL Server a SQL Database.

Informace o pokynech k návrhu indexu najdete v průvodce návrhem indexu SQL Serveru.

Příklady :

  1. Vytvoření neclusterovaného indexu v tabulce nebo zobrazení

    CREATE INDEX index1 ON schema1.table1 (column1);
    
  2. Vytvoření clusterovaného indexu v tabulce a použití názvu třetí části tabulky

    CREATE CLUSTERED INDEX index1 ON database1.schema1.table1 (column1);
    
  3. Vytvoření neclusterovaného indexu s jedinečným omezením a určení pořadí řazení

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

Scénář klíče :

Počínaje SQL Serverem 2016 (13.x) a službou SQL Database můžete ke zlepšení výkonu dotazů datového skladu použít neclusterovaný index indexu columnstore. Další informace najdete v tématu Indexy columnstore –datového skladu .

Další typy indexů najdete tady:

Transact-SQL konvence syntaxe

Syntax

Syntaxe pro SQL Server, Azure SQL Database, Azure SQL Managed Instance

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>

Zpětně kompatibilní relační index

Důležitý

Struktura syntaxe zpětně kompatibilního relačního indexu se odebere v budoucí verzi SQL Serveru. Nepoužívejte tuto strukturu syntaxe v nové vývojové práci a naplánujte úpravu aplikací, které tuto funkci aktuálně používají. Místo toho použijte strukturu syntaxe zadanou v <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
}

Syntaxe pro Azure Synapse Analytics a paralelní datový sklad


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 } )
[;]

Argumenty

JEDINEČNÝ

Vytvoří jedinečný index v tabulce nebo zobrazení. Jedinečný index je jeden, ve kterém nejsou povoleny žádné dva řádky mají stejnou hodnotu klíče indexu. Clusterovaný index v zobrazení musí být jedinečný.

Databázový stroj neumožňuje vytvořit jedinečný index u sloupců, které již obsahují duplicitní hodnoty, bez ohledu na to, jestli je IGNORE_DUP_KEY nastavena na hodnotu ZAPNUTO. Pokud to zkusíte, databázový stroj zobrazí chybovou zprávu. Před vytvořením jedinečného indexu ve sloupci nebo sloupcích je nutné odebrat duplicitní hodnoty. Sloupce, které se používají v jedinečném indexu, by měly být nastaveny na HODNOTU NOT NULL, protože při vytvoření jedinečného indexu se považuje za duplicitní hodnoty více hodnot null.

NASHROMÁŽDĚNÝ

Vytvoří index, ve kterém logické pořadí hodnot klíče určuje fyzické pořadí odpovídajících řádků v tabulce. Dolní nebo listová úroveň clusterovaného indexu obsahuje skutečné datové řádky tabulky. Tabulka nebo zobrazení je najednou povolen jeden clusterovaný index.

Zobrazení s jedinečným clusterovaným indexem se nazývá indexované zobrazení. Vytvoření jedinečného clusterovaného indexu v zobrazení fyzicky materializuje zobrazení. Jedinečný clusterovaný index musí být vytvořen v zobrazení, aby bylo možné definovat všechny ostatní indexy ve stejném zobrazení. Další informace naleznete v tématu Vytvoření indexovaných zobrazení.

Před vytvořením neclusterovaných indexů vytvořte clusterovaný index. Existující neclusterované indexy v tabulkách se znovu sestaví při vytvoření clusterovaného indexu.

Pokud není zadaný CLUSTERED, vytvoří se neclusterovaný index.

Poznámka

Vzhledem k tomu, že úroveň listu clusterovaného indexu a datových stránek jsou stejné podle definice, vytvoření clusterovaného indexu a použití klauzule ON partition_scheme_name nebo ON filegroup_name efektivně přesune tabulku ze skupiny souborů, na které byla tabulka vytvořena, do nového schématu oddílů nebo skupiny souborů. Před vytvořením tabulek nebo indexů v konkrétních skupinách souborů ověřte, které skupiny souborů jsou k dispozici a že mají dostatek volného místa pro index.

V některých případech může vytváření clusterovaného indexu povolit dříve zakázané indexy. Další informace naleznete v tématu Povolit indexy a omezení a Zakázat indexy a omezení.

NECLUSTERED

Vytvoří index, který určuje logické řazení tabulky. U neclusterovaného indexu je fyzické pořadí řádků dat nezávislé na jejich indexovaných pořadích.

Každá tabulka může mít až 999 neclusterovaných indexů bez ohledu na to, jak se indexy vytvářejí: buď implicitně s omezeními PRIMARY KEY a UNIQUE, nebo explicitně s CREATE INDEX.

U indexovaných zobrazení lze neclusterované indexy vytvořit pouze v zobrazení, které má již definovaný jedinečný clusterovaný index.

Pokud není zadán jinak, výchozí typ indexu neníclusterovaný.

index_name

Název indexu. Názvy indexů musí být jedinečné v rámci tabulky nebo zobrazení, ale nemusí být jedinečné v rámci databáze. Názvy indexů musí dodržovat pravidla identifikátorů .

sloupce

Sloupec nebo sloupce, na kterých je index založen. Zadejte dva nebo více názvů sloupců pro vytvoření složeného indexu pro kombinované hodnoty v zadaných sloupcích. Uveďte sloupce, které mají být zahrnuty do složeného indexu v pořadí podle priority řazení, uvnitř závorek za table_or_view_name.

Do jednoho složeného indexového klíče je možné zkombinovat až 32 sloupců. Všechny sloupce ve složené indexové klíči musí být ve stejné tabulce nebo zobrazení. Maximální povolená velikost kombinovaných hodnot indexu je 900 bajtů pro clusterovaný index nebo 1 700 pro neclusterovaný index. Limity jsou 16 sloupců a 900 bajtů pro verze před SQL Database a SQL Serverem 2016 (13.x).

Sloupce, které jsou datovými typy velkého objektu (LOB), ntext, textové, varchar(max), nvarchar(max), varbinary(max), xmlnebo obrázku nelze zadat jako klíčové sloupce indexu. Definice zobrazení také nemůže obsahovat ntextové, textovénebo obrázku sloupce, i když nejsou odkazovány v příkazu CREATE INDEX.

Indexy můžete vytvořit ve sloupcích typu definovaných uživatelem CLR, pokud typ podporuje binární řazení. Indexy můžete vytvořit také u počítaných sloupců, které jsou definované jako vyvolání metody ze sloupce definovaného uživatelem, pokud jsou metody označené deterministické a neprovádějí operace přístupu k datům. Další informace o indexování sloupců uživatelsky definovaných typů CLR naleznete v tématu typy definované uživatelem CLR.

[ ASC | DESC ]

Určuje vzestupný nebo sestupný směr řazení pro konkrétní sloupec indexu. Výchozí hodnota je ASC .

INCLUDE (sloupec [ ,... n ] )

Určuje sloupce bez klíče, které se mají přidat na úroveň listu neclusterovaného indexu. Neclusterovaný index může být jedinečný nebo ne jedinečný.

Názvy sloupců nelze v seznamu INCLUDE opakovat a nelze je použít současně jako klíčové i neklíčové sloupce. Neclusterované indexy vždy obsahují sloupce clusterovaného indexu, pokud je v tabulce definován clusterovaný index. Další informace najdete v tématu Vytvoření indexů se zahrnutými sloupci.

Všechny datové typy jsou povoleny s výjimkou textové, textu a obrázku. Počínaje SQL Serverem 2012 (11.x) a službou Azure SQL Database platí, že pokud některý ze zadaných sloupců bez klíčů varchar(max), nvarchar(max)nebo varbinary(max) datových typů, můžete index sestavit nebo znovu sestavit pomocí možnosti ONLINE.

Počítané sloupce, které jsou deterministické a přesné nebo nepřesné, můžou být zahrnuté sloupce. Vypočítané sloupce odvozené z obrázku, ntextové, textové, varchar(max), nvarchar(max), varbinary(max)a xml datových typů lze zahrnout do sloupců, které nejsou klíčové, pokud jsou datové typy počítaného sloupce povolené jako zahrnutý sloupec. Další informace najdete v tématu Indexy vypočítaných sloupců.

Informace o vytvoření indexu XML naleznete v tématu CREATE XML INDEX.

WHERE <filter_predicate>

Vytvoří filtrovaný index zadáním řádků, které se mají zahrnout do indexu. Filtrovaný index musí být neclusterovaný index tabulky. Vytvoří filtrované statistiky pro řádky dat ve filtrovaného indexu.

Predikát filtru používá jednoduchou porovnávací logiku a nemůže odkazovat na počítaný sloupec, sloupec UDT, sloupec prostorového datového typu nebo sloupec datového typu HierarchyID. Porovnání používající NULL literály nejsou povoleny s relačními operátory. Místo toho použijte operátory IS NULL a IS NOT NULL.

Tady je několik příkladů predikátů filtru pro tabulku Production.BillOfMaterials:

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

WHERE ComponentID IN (533, 324, 753)

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

Filtrované indexy se nevztahují na indexy XML a fulltextové indexy. U indexů UNIQUE musí mít pouze vybrané řádky jedinečné hodnoty indexu. Filtrované indexy neumožňují možnost IGNORE_DUP_KEY.

ON partition_scheme_name ( column_name )

Určuje schéma oddílů, které definuje skupiny souborů, na které se namapují oddíly děleného indexu. Schéma oddílů musí existovat v databázi spuštěním příkazu CREATE PARTITION SCHEME nebo ALTER PARTITION SCHEME. column_name určuje sloupec, podle kterého bude dělený index rozdělený. Tento sloupec musí odpovídat datovému typu, délce a přesnosti argumentu funkce oddílu, který partition_scheme_name používá. column_name nejsou omezeny na sloupce v definici indexu. Můžete zadat libovolný sloupec v základní tabulce s výjimkou dělení indexu UNIQUE, column_name je nutné vybrat z nich, které se používají jako jedinečný klíč. Toto omezení umožňuje databázovému stroji ověřit jedinečnost hodnot klíčů pouze v rámci jednoho oddílu.

Poznámka

Když rozdělíte ne jedinečné clusterované indexy, databázový stroj ve výchozím nastavení přidá sloupec dělení do seznamu clusterovaných indexových klíčů, pokud ještě není zadaný. Při dělení nevýznamného neclusterovaného indexu přidá databázový stroj sloupec dělení jako sloupec bez klíče (zahrnutého) indexu, pokud ještě není zadaný.

Pokud partition_scheme_name nebo skupinu souborů nezadáte a tabulka se rozdělí, index se umístí do stejného schématu oddílů pomocí stejného sloupce dělení jako podkladová tabulka.

Poznámka

V indexu XML nelze zadat schéma dělení. Pokud je základní tabulka rozdělená na oddíly, index XML používá stejné schéma oddílů jako tabulka.

Další informace o dělení indexů dělené tabulky a indexy.

ZAPNUTO filegroup_name

Vytvoří zadaný index pro zadanou skupinu souborů. Pokud není zadáno žádné umístění a tabulka nebo zobrazení nejsou rozdělené na oddíly, index použije stejnou skupinu souborů jako podkladová tabulka nebo zobrazení. Skupina souborů už musí existovat.

ZAPNUTO "výchozí"

Vytvoří zadaný index ve stejné skupině souborů nebo schématu oddílů jako tabulka nebo zobrazení.

Výchozí termín v tomto kontextu není klíčové slovo. Jedná se o identifikátor výchozí skupiny souborů a musí být oddělený, jako v ON "default" nebo ON [default]. Pokud je zadána možnost výchozí, musí být pro aktuální relaci možnost QUOTED_IDENTIFIER zapnutá. Toto je výchozí nastavení. Další informace naleznete v tématu SET QUOTED_IDENTIFIER.

Poznámka

Výchozí hodnota indikuje výchozí skupinu souborů databáze v kontextu CREATE INDEX. To se liší od CREATE TABLE, kde "výchozí" vyhledá tabulku ve výchozí skupině souborů databáze.

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

Určuje umístění dat FILESTREAM pro tabulku při vytvoření clusterovaného indexu. Klauzule FILESTREAM_ON umožňuje přesun dat FILESTREAM do jiného schématu filegroup nebo oddílu FILESTREAM.

filestream_filegroup_name je název filegroup FILESTREAM. Skupina souborů musí mít jeden soubor definovaný pro skupinu souborů pomocí příkazu CREATE DATABASE nebo ALTER DATABASE; v opačném případě se vyvolá chyba.

Pokud je tabulka rozdělená na oddíly, musí být zahrnuta klauzule FILESTREAM_ON a musí určovat schéma oddílů souborových skupin FILESTREAM, které používá stejnou funkci oddílu a sloupce oddílů jako schéma oddílů pro tabulku. V opačném případě se vyvolá chyba.

Pokud tabulka není rozdělená na oddíly, sloupec FILESTREAM nemůže být rozdělený na oddíly. Data FILESTREAM pro tabulku musí být uložena v jedné skupině souborů, která je zadána v klauzuli FILESTREAM_ON.

FILESTREAM_ON NULL lze zadat v příkazu CREATE INDEX, pokud se vytváří clusterovaný index a tabulka neobsahuje sloupec FILESTREAM.

Další informace naleznete v tématu FILESTREAM (SQL Server).

>objektu <::=

Plně kvalifikovaný nebo nekvalifikovaný objekt, který se má indexovat.

database_name

Název databáze.

schema_name

Název schématu, do kterého patří tabulka nebo zobrazení.

table_or_view_name

Název tabulky nebo zobrazení, které se má indexovat.

Zobrazení musí být definováno pomocí SCHEMABINDING, aby se v něm vytvořil index. Před vytvořením neclusterovaného indexu musí být v zobrazení vytvořen jedinečný clusterovaný index. Další informace o indexovaných zobrazeních najdete v části Poznámky.

Počínaje SQL Serverem 2016 (13.x) může být objekt tabulkou uloženou s clusterovaným indexem columnstore.

Azure SQL Database podporuje formát třídílných názvů database_name. [schema_name].object_name, když je database_name aktuální databází nebo database_nametempdb a object_name začíná na #.

<relational_index_option>::=

Určuje možnosti, které se mají použít při vytváření indexu.

PAD_INDEX = { ON | VYPNUTO }

Určuje odsazení indexu. Výchozí hodnota je VYPNUTO.

NA
Procento volného místa určeného fillfactor se použije na stránky indexu na střední úrovni.

Nezadá se fillfactor
Zprostředkující stránky jsou vyplněné na blízkou kapacitě a dostatek místa pro alespoň jeden řádek maximální velikosti indexu může mít vzhledem k sadě klíčů na přechodných stránkách.

Možnost PAD_INDEX je užitečná pouze v případě, že je zadána funkce FILLFACTOR, protože PAD_INDEX používá procento určené parametrem FILLFACTOR. Pokud procento zadané pro FILLFACTOR není dostatečně velké, aby umožňovalo jeden řádek, databázový stroj interně přepíše procento tak, aby umožňovalo minimum. Počet řádků na zprostředkující indexové stránce není nikdy menší než dva, bez ohledu na to, jak nízká hodnota fillfactor.

V zpětně kompatibilní syntaxi je WITH PAD_INDEX ekvivalentní WITH PAD_INDEX = ON.

FILLFACTOR = fillfactor

Určuje procento, které určuje, jak by měl databázový stroj během vytváření nebo opětovného sestavení vytvořit úroveň listu každé stránky indexu. Hodnota fillfactor musí být celočíselná hodnota od 1 do 100. Hodnoty výplňového faktoru 0 a 100 jsou ve všech ohledech stejné. Pokud fillfactor je 100, databázový stroj vytvoří indexy s listovými stránkami vyplněnými do kapacity.

Nastavení FILLFACTOR platí pouze v případech, kdy se index vytvoří nebo znovu sestaví. Databázový stroj dynamicky neuchová zadané procento prázdného místa na stránkách.

Chcete-li zobrazit nastavení faktoru výplně, použijte fill_factor v sys.indexes.

Důležitý

Vytvoření clusterovaného indexu s FILLFACTOR menší než 100 ovlivňuje velikost úložného prostoru, který data zabírá, protože databázový stroj redistribuuje data při vytváření clusterovaného indexu.

Další informace najdete v tématu Určení faktoru vyplnění indexu.

SORT_IN_TEMPDB = { ON | VYPNUTO }

Určuje, zda se mají ukládat dočasné výsledky řazení do databáze tempdb. Výchozí hodnota je vypnutá s výjimkou hyperškálování služby Azure SQL Database. U všech operací sestavení indexu v Hyperscale je SORT_IN_TEMPDB vždy zapnuto bez ohledu na zadanou možnost, pokud se nepoužijí opětovné sestavení indexu.

NA
Přechodné výsledky řazení, které se používají k sestavení indexu, jsou uloženy v databáze tempdb. To může zkrátit dobu potřebnou k vytvoření indexu, pokud databáze tempdb je na jiné sadě disků než uživatelská databáze. Tím se ale zvýší množství místa na disku, které se použije při sestavení indexu.

PRYČ
Výsledky zprostředkujícího řazení jsou uloženy ve stejné databázi jako index.

Kromě místa potřebného k vytvoření indexu v uživatelské databázi musí databáze tempdb mít přibližně stejné množství místa pro uložení výsledků přechodného řazení. Další informace naleznete v tématu SORT_IN_TEMPDB možnost indexů.

V zpětně kompatibilní syntaxi je WITH SORT_IN_TEMPDB ekvivalentní WITH SORT_IN_TEMPDB = ON.

IGNORE_DUP_KEY = { ON | VYPNUTO }

Určuje chybovou odpověď, když se operace vložení pokusí vložit duplicitní hodnoty klíče do jedinečného indexu. Možnost IGNORE_DUP_KEY se vztahuje pouze na operace vložení po vytvoření nebo vytvoření indexu. Možnost nemá žádný vliv při provádění CREATE INDEX, ALTER INDEXnebo UPDATE. Výchozí hodnota je VYPNUTO.

NA
Při vložení duplicitních hodnot klíče do jedinečného indexu se zobrazí zpráva s upozorněním. Pouze řádky, které porušují omezení jedinečnosti, selžou.

PRYČ
Při vložení duplicitních hodnot klíče do jedinečného indexu se zobrazí chybová zpráva. Celá operace INSERT se vrátí zpět.

IGNORE_DUP_KEY nelze nastavit na hodnotu ZAPNUTO pro indexy vytvořené v zobrazení, ne jedinečné indexy, indexy XML, prostorové indexy a filtrované indexy.

Chcete-li zobrazit , použijtesys.indexes .

V zpětně kompatibilní syntaxi je WITH IGNORE_DUP_KEY ekvivalentní WITH IGNORE_DUP_KEY = ON.

STATISTICS_NORECOMPUTE = { ON | VYPNUTO}

Určuje, jestli se přepočítají statistiky distribuce. Výchozí hodnota je VYPNUTO.

NA
Zastaralé statistiky se automaticky nepřepočítají.

PRYČ
Jsou povoleny automatické aktualizace statistik.

Pokud chcete obnovit automatickou aktualizaci statistik, nastavte STATISTICS_NORECOMPUTE na OFF nebo spusťte UPDATE STATISTICS bez klauzule NORECOMPUTE.

Důležitý

Zakázání automatického přepočtu distribučních statistik může zabránit optimalizaci dotazů v výběru optimálních plánů spuštění pro dotazy zahrnující tabulku.

V zpětně kompatibilní syntaxi je WITH STATISTICS_NORECOMPUTE ekvivalentní WITH STATISTICS_NORECOMPUTE = ON.

STATISTICS_INCREMENTAL = { ON | VYPNUTO }

platí pro: SQL Server (počínaje SQL Serverem 2014 (12.x)) a Azure SQL Database

Při ONse vytvoří statistika na statistiky oddílů. Když VYPNUTO, strom statistiky se zahodí a SQL Server znovu vypočítá statistiku. Výchozí hodnota je VYPNUTO.

Pokud statistiky jednotlivých oddílů nejsou podporované, možnost se ignoruje a vygeneruje se upozornění. Přírůstkové statistiky nejsou podporovány pro následující typy statistik:

  • Statistiky vytvořené pomocí indexů, které nejsou v souladu se základní tabulkou
  • Statistiky vytvořené v sekundárních databázích s možností čtení AlwaysOn
  • Statistiky vytvořené pro databáze jen pro čtení
  • Statistiky vytvořené pro filtrované indexy
  • Statistiky vytvořené v zobrazeních
  • Statistiky vytvořené v interních tabulkách
  • Statistiky vytvořené pomocí prostorových indexů nebo indexů XML

DROP_EXISTING = { ON | VYPNUTO }

Je možnost odstranit a znovu sestavit existující clusterovaný nebo neclusterovaný index s upravenými specifikacemi sloupců a zachovat stejný název indexu. Výchozí hodnota je VYPNUTO.

NA
Určuje, že chcete odstranit a znovu sestavit existující index, který musí mít stejný název jako parametr index_name.

PRYČ
Určuje, že se má existující index vynechat a znovu sestavit. SQL Server zobrazí chybu, pokud zadaný název indexu již existuje.

Pomocí DROP_EXISTINGmůžete změnit:

  • Neclusterovaný index rowstore do clusterovaného indexu rowstore.

V DROP_EXISTINGnemůžete změnit:

  • Clusterovaný index rowstore do neclusterovaného indexu rowstore.
  • Clusterovaný index columnstore libovolného typu indexu rowstore.

V zpětně kompatibilní syntaxi je WITH DROP_EXISTING ekvivalentní WITH DROP_EXISTING = ON.

ONLINE = { ON | VYPNUTO }

Určuje, jestli jsou podkladové tabulky a přidružené indexy dostupné pro dotazy a úpravy dat během operace indexu. Výchozí hodnota je VYPNUTO.

Důležitý

Online indexovací operace nejsou k dispozici v každé edici Microsoft SQL Serveru. Seznam funkcí podporovaných edicemi SQL Serveru najdete v tématu Edice a podporované funkce systému SQL Server 2022.

NA
Dlouhodobé zámky tabulek se neuchovávají po dobu trvání operace indexu. Během hlavní fáze operace indexu se ve zdrojové tabulce uchovává pouze zámek sdílení záměru (IS). To umožňuje pokračovat v dotazech nebo aktualizacích podkladové tabulky a indexů. Na začátku operace se na zdrojovém objektu uchovává zámek Shared (S) po velmi krátkou dobu. Na konci operace se po krátkou dobu získá zámek S (Shared) ve zdroji, pokud se vytváří neclusterovaný index. Zámek Sch-M (úprava schématu) se získá při vytvoření nebo vyřazení clusterovaného indexu online a při vytvoření clusterovaného nebo neclusterovaného indexu. Při vytváření indexu v místní dočasné tabulce není možné nastavit hodnotu ON.ONLINE.

Poznámka

Vytváření online indexů může nastavit možnosti low_priority_lock_wait, viz WAIT_AT_LOW_PRIORITY s operacemi online indexu.

PRYČ
Zámky tabulek se použijí po dobu trvání operace indexu. Operace offline indexu, která vytvoří, znovu sestaví nebo zahodí clusterovaný index nebo znovu sestaví nebo zamkne neclusterovaný index, získá v tabulce zámek schématu (Sch-M). Tím zabráníte všem uživatelům přístup k podkladové tabulce po dobu trvání operace. Operace offline indexu, která vytvoří neclusterovaný index, získá v tabulce zámek Shared (S). To brání aktualizacím podkladové tabulky, ale umožňuje operace čtení, jako jsou příkazy SELECT.

Další informace naleznete v tématu Provádění operací indexu online.

Indexy, včetně indexů v globálních dočasných tabulkách, lze vytvořit online s výjimkou následujících případů:

  • Index XML
  • Indexování místní dočasné tabulky
  • Počáteční jedinečný clusterovaný index v zobrazení
  • Zakázané clusterované indexy
  • Clusterované indexy columnstore v SQL Serveru 2017 (14.x)) a starší
  • Neclusterované indexy columnstore v SQL Serveru 2016 (13.x) a starších
  • Skupinový index, pokud podkladová tabulka obsahuje datové typy LOB (image, ntext, text) a prostorové datové typy
  • varchar(max) a varbinary(max) sloupce nemůžou být součástí indexového klíče. V SQL Serveru (počínaje SQL Serverem 2012 (11.x)) a Azure SQL Database platí, že pokud tabulka obsahuje varchar(max) nebo varbinary(max) sloupce, můžete vytvořit nebo znovu sestavit clusterovaný index obsahující další sloupce pomocí možnosti ONLINE.
  • Neclusterované indexy v tabulce s clusterovaným indexem columnstore

Další informace najdete v tématu Fungování operací indexu online.

RESUMABLE = { ON | VYPNUTO }

platí pro: SQL Server (počínaje SQL Serverem 2019 (15.x)) a Azure SQL Database

Určuje, jestli je operace online indexu obnovitelná.

NA
Operace indexu je obnovitelná.

PRYČ
Operace indexu není obnovitelná.

MAX_DURATION = čas [MINUTES] použitý s RESUMABLE = ON (vyžaduje ONLINE = ON)

platí pro: SQL Server (počínaje SQL Serverem 2019 (15.x)) a Azure SQL Database

Určuje čas (celočíselná hodnota zadaná v minutách), že se před pozastavením provede operace obnovitelného online indexu.

Důležitý

Podrobnější informace o operacích indexu, které lze provádět online, naleznete v tématu Pokyny pro online indexovací operace.

Poznámka

Opětovné sestavení online indexu není podporováno u indexů columnstore ani zakázaných indexů.

ALLOW_ROW_LOCKS = { ON | VYPNUTO }

Určuje, jestli jsou povolené zámky řádků. Výchozí hodnota je ZAPNUTO.

NA
Zámky řádků jsou povoleny při přístupu k indexu. Databázový stroj určuje, kdy se používají zámky řádků.

PRYČ
Zámky řádků se nepoužívají.

ALLOW_PAGE_LOCKS = { ON | VYPNUTO }

Určuje, jestli jsou povolené zámky stránek. Výchozí hodnota je ZAPNUTO.

NA
Zámky stránek jsou povoleny při přístupu k indexu. Databázový stroj určuje, kdy se používají zámky stránek.

PRYČ
Zámky stránek se nepoužívají.

OPTIMIZE_FOR_SEQUENTIAL_KEY = { ON | VYPNUTO }

platí pro: SQL Server (počínaje SQL Serverem 2019 (15.x)) a Azure SQL Database

Určuje, jestli se má optimalizovat pro kolizí vložení poslední stránky. Výchozí hodnota je VYPNUTO. Další informace najdete v části Sekvenční klíče.

MAXDOP = max_degree_of_parallelism

Po dobu trvání operace indexu přepíše maximální stupeň paralelismu možnost konfigurace. Další informace najdete v tématu Konfigurace maximálního stupně paralelismu Možnosti konfigurace serveru. Pomocí funkce MAXDOP omezte počet procesorů používaných při paralelním provádění plánu. Maximum je 64 procesorů.

max_degree_of_parallelism může být:

1
Potlačí generování paralelního plánu.

>1
Omezuje maximální počet procesorů používaných v paralelní operaci indexu na zadané číslo nebo méně na základě aktuální systémové úlohy.

0 (výchozí)
Používá skutečný počet procesorů nebo méně na základě aktuální systémové úlohy.

Další informace najdete v tématu Konfigurace operací paralelního indexu.

Poznámka

Paralelní indexovací operace nejsou k dispozici v každé edici Microsoft SQL Serveru. Seznam funkcí podporovaných edicemi SQL Serveru najdete v tématu Edice a podporované funkce systému SQL Server 2022.

DATA_COMPRESSION

Určuje možnost komprese dat pro zadaný index, číslo oddílu nebo rozsah oddílů. Možnosti jsou následující:

ŽÁDNÝ
Indexované nebo zadané oddíly nejsou komprimovány.

VESLOVAT
Indexované nebo zadané oddíly se komprimují pomocí komprese řádků.

STRÁNKA
Index nebo zadané oddíly se komprimují pomocí komprese stránky.

Další informace o kompresi naleznete v tématu Komprese dat.

XML_COMPRESSION

platí pro: SQL Server 2022 (16.x) a novější verze, Azure SQL Database a Azure SQL Managed Instance.

Určuje možnost komprese XML pro zadaný index, který obsahuje jeden nebo více xml sloupce datového typu. Možnosti jsou následující:

NA
Indexování nebo zadané oddíly jsou komprimovány pomocí komprese XML.

PRYČ
Indexované nebo zadané oddíly nejsou komprimovány.

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

Určuje oddíly, na které se vztahují nastavení DATA_COMPRESSION nebo XML_COMPRESSION. Pokud index není rozdělený do oddílů, vygeneruje argument ON PARTITIONS chybu. Pokud není klauzule ON PARTITIONS k dispozici, použije se možnost DATA_COMPRESSION nebo XML_COMPRESSION pro všechny oddíly děleného indexu.

<partition_number_expression> lze zadat následujícími způsoby:

  • Zadejte číslo oddílu, například: ON PARTITIONS (2).
  • Zadejte čísla oddílů pro několik jednotlivých oddílů oddělených čárkami, například: ON PARTITIONS (1, 5).
  • Zadejte rozsahy i jednotlivé oddíly, například: ON PARTITIONS (2, 4, 6 TO 8).

<range> lze zadat jako čísla oddílů oddělená slovem TO, například: ON PARTITIONS (6 TO 8).

Pokud chcete nastavit různé typy komprese dat pro různé oddíly, zadejte DATA_COMPRESSION možnost více než jednou, například:

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)
);

Můžete také zadat XML_COMPRESSION možnost více než jednou, například:

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)
);

Poznámky

Příkaz CREATE INDEX je optimalizovaný jako jakýkoli jiný dotaz. Pokud chcete ušetřit vstupně-výstupní operace, procesor dotazů se může rozhodnout, že místo prohledávání tabulky prohledá jiný index. Operace řazení může být v některých situacích vyloučena. V počítačích s více procesory CREATE INDEX může použít více procesorů k provádění operací prohledávání a řazení spojených s vytvářením indexu stejným způsobem jako u jiných dotazů. Další informace najdete v tématu Konfigurace operací paralelního indexu.

Operace CREATE INDEX může být minimálně protokolována, pokud je model obnovení databáze nastavený na hromadně protokolovaný nebo jednoduchý.

Indexy lze vytvořit v dočasné tabulce. Po vyřazení tabulky nebo ukončení relace se indexy zahodí.

Clusterovaný index lze při vytvoření primárního klíče vytvořit na proměnné tabulky. Po dokončení dotazu nebo ukončení relace se index zahodí.

Indexy podporují rozšířené vlastnosti.

CREATE INDEX se v Microsoft Fabric nepodporuje.

Clusterované indexy

Vytvoření clusterovaného indexu v tabulce (haldě) nebo vyřazení a opětovné vytvoření existujícího clusterovaného indexu vyžaduje, aby byl v databázi k dispozici další pracovní prostor, který bude vyhovovat řazení dat, a dočasnou kopii původní tabulky nebo existujících dat clusterovaného indexu. Další informace o clusterovaných indexech naleznete v tématu Vytvoření clusterovaných indexů a sql Server Index Architecture and Design Guide.

Neclusterované indexy

Počínaje SQL Serverem 2016 (13.x) a v Azure SQL Database můžete vytvořit neclusterovaný index v tabulce uložené jako clusterovaný index columnstore. Pokud nejprve vytvoříte neclusterovaný index v tabulce uložené jako haldu nebo clusterovaný index, index se zachová, pokud později převedete tabulku na clusterovaný index columnstore. Při opětovném sestavení clusterovaného indexu columnstore není také nutné vynechat neclusterovaný index.

Omezení a omezení:

  • Možnost FILESTREAM_ON není platná při vytváření neclusterovaného indexu v tabulce uložené jako clusterovaný index columnstore.

Jedinečné indexy

Pokud existuje jedinečný index, databázový stroj kontroluje duplicitní hodnoty při každém přidání dat operacemi vložení. Operace vložení, které by vygenerovaly duplicitní hodnoty klíče, se vrátí zpět a databázový stroj zobrazí chybovou zprávu. To platí i v případě, že operace vložení změní mnoho řádků, ale způsobí pouze jeden duplikát. Pokud se pokusíte zadat data, pro která existuje jedinečný index a klauzule IGNORE_DUP_KEY je nastavená na HODNOTU ON, nezdaří se pouze řádky, které porušují index UNIQUE.

Dělené indexy

Dělené indexy se vytvářejí a udržují podobným způsobem jako dělené tabulky, ale stejně jako běžné indexy se zpracovávají jako samostatné databázové objekty. V tabulce, která není rozdělená na oddíly, můžete mít dělený index a v tabulce, která je rozdělená do oddílů, můžete mít nedílený index.

Pokud vytváříte index v dělené tabulce a nezadáte skupinu souborů, na kterou se má index umístit, index se rozdělí stejným způsobem jako podkladová tabulka. Důvodem je to, že indexy se ve výchozím nastavení umístí do stejných skupin souborů jako jejich podkladové tabulky a pro dělenou tabulku ve stejném schématu oddílů, které používají stejné sloupce dělení. Pokud index používá stejné schéma oddílů a sloupec dělení jako tabulka, index je zarovnaný s tabulkou.

Varování

Vytvoření a opětovné sestavení nerovnaných indexů v tabulce s více než 1 000 oddíly je možné, ale nepodporuje se. To může způsobit snížení výkonu nebo nadměrné využití paměti během těchto operací. Doporučujeme použít pouze zarovnané indexy, pokud počet oddílů překročí 1 000.

Při dělení ne jedinečného clusterovaného indexu databázový stroj ve výchozím nastavení přidá do seznamu clusterovaných indexových klíčů všechny sloupce dělení, pokud ještě nejsou zadané.

Indexovaná zobrazení lze vytvořit v dělených tabulkách stejným způsobem jako indexy v tabulkách. Další informace o dělených indexech naleznete v tématu Dělené tabulky a indexy a sql Server Index Architecture and Design Guide.

V SQL Serveru se statistiky nevytvořily prohledáváním všech řádků v tabulce při vytvoření nebo vytvoření děleného indexu. Místo toho optimalizátor dotazů používá k vygenerování statistik výchozí algoritmus vzorkování. Pokud chcete získat statistiky o dělených indexech prohledáváním všech řádků v tabulce, použijte CREATE STATISTICS nebo UPDATE STATISTICS s klauzulí FULLSCAN.

Filtrované indexy

Filtrovaný index je optimalizovaný neclusterovaný index, který je vhodný pro dotazy, které z tabulky vyberou malé procento řádků. Používá predikát filtru k indexování části dat v tabulce. Dobře navržený filtrovaný index může zlepšit výkon dotazů, snížit náklady na úložiště a snížit náklady na údržbu.

Požadované možnosti SET pro filtrované indexy

Možnosti SET ve sloupci Požadovaná hodnota se vyžadují vždy, když dojde k některé z následujících podmínek:

  • Vytvořte filtrovaný index.

  • Operace INSERT, UPDATE, DELETE nebo MERGE upraví data ve filtrovaného indexu.

  • Filtrovaný index používá optimalizátor dotazů k vytvoření plánu dotazu.

    Možnosti SET Požadovaná hodnota Výchozí hodnota serveru Výchozí

    Hodnota OLE DB a ODBC
    Výchozí

    hodnota DB-Library
    ANSI_NULLS NA NA NA PRYČ
    ANSI_PADDING NA NA NA PRYČ
    ANSI_WARNINGS* NA NA NA PRYČ
    ARITHABORT NA NA PRYČ PRYČ
    CONCAT_NULL_YIELDS_NULL NA NA NA PRYČ
    NUMERIC_ROUNDABORT PRYČ PRYČ PRYČ PRYČ
    QUOTED_IDENTIFIER NA NA NA PRYČ
    • Nastavení ANSI_WARNINGS na HODNOTU ON implicitně nastaví ARITHABORT na HODNOTU ON, pokud je úroveň kompatibility databáze nastavená na 90 nebo vyšší. Pokud je úroveň kompatibility databáze nastavená na hodnotu 80 nebo starší, musí být možnost ARITHABORT explicitně nastavená na hodnotu ON.

Pokud jsou možnosti SET nesprávné, mohou nastat následující podmínky:

  • Filtrovaný index se nevytvořil.
  • Databázový stroj vygeneruje chybu a vrátí příkazy INSERT, UPDATE, DELETE nebo MERGE, které mění data v indexu.
  • Optimalizátor dotazů nebere v plánu provádění index pro žádné příkazy Transact-SQL.

Další informace o filtrovaných indexech naleznete v tématu Vytvoření filtrovaných indexů a sql Server Index Architecture and Design Guide.

Prostorové indexy

Informace o prostorových indexech naleznete v tématu CREATE SPATIAL INDEX a Spatial Indexes Overview.

Indexy XML

Informace o indexech XML naleznete CREATE XML INDEX a XML Indexy (SQL Server).

Velikost klíče indexu

Maximální velikost klíče indexu je 900 bajtů pro clusterovaný index a 1 700 bajtů pro neclusterovaný index. (Před SQL Database a SQL Serverem 2016 (13.x) byl limit vždy 900 bajtů.) Indexy u varchar sloupců, které překračují limit bajtů, lze vytvořit, pokud existující data ve sloupcích nepřekročí limit v době vytvoření indexu; Následné akce vložení nebo aktualizace sloupců, které způsobí, že celková velikost bude větší než limit, se nezdaří. Klíč indexu clusterovaného indexu nemůže obsahovat varchar sloupce, které obsahují existující data v jednotce přidělení ROW_OVERFLOW_DATA. Pokud je clusterovaný index vytvořen ve sloupci varchar a existující data jsou v jednotce přidělení IN_ROW_DATA, následné akce vložení nebo aktualizace ve sloupci, které by nasdílely data mimo řádek, selžou.

Neclusterované indexy můžou obsahovat sloupce bez klíče na úrovni listu indexu. Tyto sloupce databázový stroj při výpočtu velikosti klíče indexu nepovažuje za tyto sloupce . Další informace najdete v tématu Vytvoření indexů se zahrnutými sloupci aprůvodce architektury indexu SQL Serveru a návrhu .

Poznámka

Pokud jsou tabulky rozdělené na oddíly, sloupce klíče dělení ještě nejsou v ne jedinečném clusterovém indexu, přidají se do indexu databázovým strojem. Kombinovaná velikost indexovaných sloupců (nepočítají se zahrnuté sloupce) a žádné přidané sloupce dělení nesmí překročit 1800 bajtů v ne jedinečném clusterovém indexu.

Počítané sloupce

Indexy je možné vytvořit na počítaných sloupcích. Počítané sloupce navíc můžou mít vlastnost PERSISTED. To znamená, že databázový stroj ukládá vypočítané hodnoty v tabulce a aktualizuje je, když se aktualizují všechny další sloupce, na kterých závisí vypočítaný sloupec. Databázový stroj používá tyto trvalé hodnoty při vytváření indexu ve sloupci a při odkazování na index v dotazu.

Aby bylo možné indexovat vypočítaný sloupec, musí být vypočítaný sloupec deterministický a přesný. Použití vlastnosti PERSISTED ale rozšiřuje typ indexovatelných vypočítaných sloupců, aby zahrnoval:

  • Počítané sloupce založené na funkcích Transact-SQL a CLR a metodách typů definovaných uživatelem CLR, které jsou označeny deterministicky uživatelem.
  • Počítané sloupce založené na výrazech, které jsou deterministické podle definice databázového stroje, ale nepřesné.

Trvalé počítané sloupce vyžadují, aby byly nastaveny následující možnosti SET, jak je znázorněno v předchozí části Požadované možnosti SET pro filtrované indexy.

Omezení UNIQUE nebo PRIMARY KEY může obsahovat počítaný sloupec, pokud splňuje všechny podmínky pro indexování. Konkrétně musí být vypočítaný sloupec deterministický a přesný nebo deterministický a trvalý. Další informace o determinismu naleznete v tématu Deterministické a nedeterministické funkce.

Vypočítané sloupce odvozené zobrázku , ntext, textové, varchar(max), nvarchar(max), varbinary(max)a xml datových typů lze indexovat buď jako klíč, nebo zahrnout sloupec bez klíče, pokud je datový typ vypočítaného sloupce povolený jako sloupec s klíčem indexu nebo neklíčový sloupec. Nemůžete například vytvořit primární index XML ve vypočítané xml sloupci. Pokud velikost klíče indexu přesahuje 900 bajtů, zobrazí se zpráva s upozorněním.

Vytvoření indexu ve vypočítaném sloupci může způsobit selhání operace vložení nebo aktualizace, která dříve fungovala. K takovému selhání může dojít, když vypočítaný sloupec způsobí aritmetickou chybu. Například v následující tabulce, i když vypočítaný sloupec c vede k aritmetické chybě, příkaz INSERT funguje.

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

Pokud místo toho po vytvoření tabulky vytvoříte index pro počítaný sloupec c, stejný příkaz INSERT nyní selže.

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);

Další informace najdete v tématu Indexy vypočítaných sloupců.

Zahrnuté sloupce v indexech

Neklíčové sloupce, označované jako zahrnuté sloupce, lze přidat na úroveň listu neclusterovaného indexu, aby se zlepšil výkon dotazů pokrytím dotazu. To znamená, že všechny sloupce odkazované v dotazu se do indexu zahrnou jako klíčové nebo neklíčové sloupce. To umožňuje optimalizátoru dotazů vyhledat všechny požadované informace z prohledávání indexu; k tabulce nebo clusterovaným datům indexu se nepřistupuje. Další informace najdete v tématu Vytvoření indexů se zahrnutými sloupci aprůvodce architektury indexu SQL Serveru a návrhu .

Určení možností indexu

SQL Server 2005 (9.x) zavedl nové možnosti indexu a také upravuje způsob, jakým jsou zadány možnosti. V zpětně kompatibilní syntaxi je WITH option_name ekvivalentní WITH (option_name = ON). Při nastavování možností indexu platí následující pravidla:

  • Nové možnosti indexu lze zadat pouze pomocí WITH (<option_name> = <ON | OFF>).
  • Možnosti nelze zadat pomocí zpětně kompatibilní i nové syntaxe ve stejném příkazu. Například zadání WITH (DROP_EXISTING, ONLINE = ON) způsobí selhání příkazu.
  • Při vytváření indexu XML je nutné zadat možnosti pomocí WITH (<option_name> = <ON | OFF>).

klauzule DROP_EXISTING

Klauzuli DROP_EXISTING můžete použít k opětovnému sestavení indexu, přidání nebo přetažení sloupců, úpravě možností řazení sloupců nebo změně schématu oddílů nebo skupiny souborů.

Pokud index vynucuje omezení PRIMÁRNÍ KLÍČ nebo UNIQUE a definice indexu se nijak nezmění, index se zahodí a znovu vytvoří zachování stávajícího omezení. Pokud je však definice indexu změněna, příkaz selže. Pokud chcete změnit definici omezení PRIMARY KEY nebo UNIQUE, přetáhněte omezení a přidejte omezení s novou definicí.

DROP_EXISTING zvyšuje výkon při opětovném vytvoření clusterovaného indexu se stejnou nebo jinou sadou klíčů v tabulce, která má také neclusterované indexy. DROP_EXISTING nahradí spuštění příkazu DROP INDEX na starém clusterovém indexu následovaného spuštěním příkazu CREATE INDEX nového clusterovaného indexu. Neclusterované indexy se znovu sestaví jednou a pak pouze v případě, že se změnila definice indexu. Klauzule DROP_EXISTING nepřebuduje neclusterované indexy, pokud má definice indexu stejný název indexu, sloupce klíčů a oddílů, atribut jedinečnosti a pořadí řazení jako původní index.

Bez ohledu na to, jestli se neclusterované indexy znovu sestaví, zůstanou vždy ve svých původních skupinách souborů nebo schématech oddílů a používají původní funkce oddílů. Pokud se clusterovaný index znovu sestaví do jiné skupiny souborů nebo schématu oddílů, nepřesouvají se neclusterované indexy tak, aby se shodovaly s novým umístěním clusterovaného indexu. Proto i neclusterované indexy, které byly dříve v souladu s clusterovaným indexem, nemusí být už s ním zarovnané. Další informace o zarovnání dělených indexů naleznete v tématu Dělené tabulky a indexy.

Klauzule DROP_EXISTING data znovu seřadí, pokud jsou stejné sloupce klíče indexu použity ve stejném pořadí a se stejným vzestupným nebo sestupným pořadím, pokud příkaz indexu neurčí neclusterovaný index a možnost ONLINE je nastavena na VYPNUTO. Pokud je clusterovaný index zakázaný, musí být operace CREATE INDEX WITH DROP_EXISTING provedena s nastavením ONLINE na VYPNUTO. Pokud je neclusterovaný index zakázaný a není přidružený k zakázanému clusterovaného indexu, je možné operaci CREATE INDEX WITH DROP_EXISTING provést s funkcí ONLINE nastavenou na VYPNUTO nebo ZAPNUTO.

Poznámka

Když se indexy s rozsahy 128 nebo více vyřadí nebo znovu sestaví, databázový stroj odblokuje skutečné přidělení stránky a jejich přidružené zámky, dokud po potvrzení transakce.

Možnost ONLINE

Pro online provádění operací indexu platí následující pokyny:

  • Podkladovou tabulku nelze změnit, zkrátit ani vynechat, když probíhá online operace indexu.
  • Během operace indexu je vyžadováno další dočasné místo na disku.
  • Online operace je možné provádět s dělenými indexy a indexy, které obsahují trvalé počítané sloupce nebo zahrnuté sloupce.
  • Možnost argumentu low_priority_lock_wait umožňuje rozhodnout, jak může operace indexu pokračovat, když je blokovaná na uzamčení Sch-M.

Další informace naleznete v tématu Provádění operací indexu online.

Prostředky

K obnovení operace vytvoření online indexu jsou vyžadovány následující zdroje informací:

  • Další místo potřebné k zachování vytváření indexu, včetně času pozastavení indexu
  • Další propustnost protokolu během fáze řazení. Celkové využití místa v protokolu pro obnovitelný index je menší než běžné vytvoření online indexu a umožňuje zkrácení protokolu během této operace.
  • Stav DDL bránící jakékoli úpravě DDL
  • Čištění duchů je v indexu v buildu blokováno po dobu trvání operace, a to jak během pozastavení, tak i v době, kdy je operace spuštěná.

Aktuální funkční omezení

Pro operace vytváření obnovitelných indexů je zakázaná následující funkce:

  • Po pozastavení operace opětovného vytvoření online indexu nelze počáteční hodnotu MAXDOP změnit.

  • Vytvořte index, který obsahuje:

    • Vypočítané sloupce nebo sloupce TIMESTAMP jako klíčové sloupce
    • Sloupec LOB jako zahrnutý sloupec pro vytvoření obnovitelného indexu
    • Filtrovaný index

Operace indexu s možností obnovení

platí pro: SQL Server (počínaje SQL Serverem 2019 (15.x)) a Azure SQL Database

Následující pokyny platí pro operace indexu s možností obnovení:

  • Vytvoření online indexu je určeno jako obnovitelné pomocí možnosti RESUMABLE = ON.
  • Možnost RESUMABLE se neuchovává v metadatech pro daný index a vztahuje se pouze na dobu trvání aktuálního příkazu DDL. Proto musí být klauzule RESUMABLE = ON zadána explicitně, aby bylo možné obnovitelnost.
  • možnost MAX_DURATION je podporována pouze pro možnost RESUMABLE = ON.
  • MAX_DURATION pro možnost RESUMABLE určuje časový interval sestavení indexu. Jakmile se tentokrát použije sestavení indexu, buď se pozastaví, nebo se dokončí jeho spuštění. Uživatel rozhodne, kdy je možné obnovit sestavení pozastaveného indexu. Doba v minutách pro MAX_DURATION musí být větší než 0 minut a menší nebo rovna jednomu týdnu (7 * 24 × 60 = 10080 minut). Dlouhé pozastavení operace indexu může mít vliv na výkon DML u konkrétní tabulky i na kapacitu disku databáze, protože oba indexy původní i nově vytvořené operace vyžadují místo na disku a je potřeba je aktualizovat během operací DML. Pokud MAX_DURATION možnost vynecháte, operace indexu bude pokračovat, dokud nedojde k jeho dokončení nebo dokud nedojde k selhání.
  • Pokud chcete okamžitě pozastavit operaci indexu, můžete zastavit probíhající příkaz (Ctrl-C), spustit příkaz ALTER INDEX PAUSE nebo spustit příkaz KILL <session_id>. Jakmile je příkaz pozastavený, můžete ho obnovit pomocí příkazu ALTER INDEX.
  • Opětovné spuštění původního příkazu CREATE INDEX pro obnovitelný index automaticky obnoví pozastavenou operaci vytvoření indexu.
  • Možnost SORT_IN_TEMPDB = ON není podporovaná pro obnovitelný index.
  • Příkaz DDL s RESUMABLE = ON nelze spustit uvnitř explicitní transakce (nelze být součástí počátečního TRAN ... COMMIT bloku).
  • Pokud chcete obnovit nebo přerušit vytvoření nebo opětovné sestavení indexu, použijte syntaxi ALTER INDEX T-SQL.
  • Zakázané indexy se nepodporují.

Poznámka

Příkaz DDL se spustí, dokud se nedokončí, pozastaví nebo selže. Pokud se příkaz pozastaví, zobrazí se chyba, která značí, že operace byla pozastavena a že se vytvoření indexu nedokončilo. Další informace o aktuálním stavu indexu lze získat z sys.index_resumable_operations. Stejně jako v případě selhání bude vydána také chyba.

Chcete-li označit, že vytvoření indexu je provedeno jako obnovitelná operace a kontrola jeho aktuálního stavu provádění, přečtěte si sys.index_resumable_operations.

WAIT_AT_LOW_PRIORITY s online indexovacími operacemi

platí pro: Tato syntaxe pro CREATE INDEX aktuálně platí jenom pro SQL Server 2022 (16.x), Azure SQL Database a Azure SQL Managed Instance. Pro ALTER INDEXplatí tato syntaxe pro SQL Server (počínaje SQL Serverem 2014 (12.x)) a službou Azure SQL Database. Další informace naleznete v tématu ALTER INDEX.

Syntaxe low_priority_lock_wait umožňuje určit chování WAIT_AT_LOW_PRIORITY. WAIT_AT_LOW_PRIORITY lze použít pouze s ONLINE=ON.

Možnost WAIT_AT_LOW_PRIORITY umožňuje dbA spravovat Sch-S a Sch-M zámky vyžadované pro vytvoření online indexu a umožňuje jim vybrat jednu ze 3 možností. Ve všech 3 případech, pokud během doby čekání MAX_DURATION = n [minutes], neexistují žádné blokující aktivity, online opětovné sestavení indexu se spustí okamžitě bez čekání a příkaz DDL se dokončí.

WAIT_AT_LOW_PRIORITY značí, že operace vytvoření online indexu bude čekat na zámky s nízkou prioritou, což umožní dalším operacím pokračovat, zatímco operace sestavení online indexu čeká. Vynechání možnosti WAIT AT LOW PRIORITY odpovídá WAIT_AT_LOW_PRIORITY (MAX_DURATION = 0 minutes, ABORT_AFTER_WAIT = NONE).

MAX_DURATION = čas [MINUTY]

Doba čekání (celočíselná hodnota zadaná v minutách), kterou online index vytvoří zámky, počká při provádění příkazu DDL s nízkou prioritou. Pokud je operace zablokovaná pro MAX_DURATION čas, provede se zadaná ABORT_AFTER_WAIT akce. MAX_DURATION čas je vždy v minutách a slovo MINUTES je možné vynechat.

ABORT_AFTER_WAIT = [NONE | SELF | BLOCKERS } ]

NONE Continue waiting for the lock with normal (regular) priority.

SELF Ukončete online index vytvoření operace DDL, která se právě spouští, aniž byste provedli žádnou akci. Možnost SELF se nedá použít s MAX_DURATION 0.

BLOCKERS Ukončete všechny uživatelské transakce, které blokují operaci DDL opětovného sestavení online indexu, aby operace nemohla pokračovat. Možnost BLOCKERS vyžaduje, aby přihlášení měla oprávnění ALTER ANY CONNECTION.

Možnosti zámků řádků a stránek

Pokud jsou při přístupu k indexu povoleny zámky na úrovni řádků, stránek a tabulek ALLOW_ROW_LOCKS = ON a ALLOW_PAGE_LOCK = ON. Databázový stroj zvolí příslušný zámek a může zámek eskalovat z řádku nebo zámku stránky na zámek tabulky.

Při ALLOW_ROW_LOCKS = OFF a ALLOW_PAGE_LOCK = OFFje při přístupu k indexu povolen pouze zámek na úrovni tabulky.

Sekvenční klávesy

platí pro: SQL Server (počínaje SQL Serverem 2019 (15.x)) a Azure SQL Database

Kolize vložení poslední stránky je běžný problém s výkonem, ke kterému dochází, když se velký počet souběžných vláken pokusí vložit řádky do indexu se sekvenčním klíčem. Index se považuje za sekvenční, pokud počáteční klíčový sloupec obsahuje hodnoty, které se neustále zvyšují (nebo snižují), například sloupec identity nebo datum, které je výchozí pro aktuální datum a čas. Protože vložené klíče jsou sekvenční, všechny nové řádky se vloží na konec struktury indexu – jinými slovy, na stejné stránce. To vede k kolizí stránky v paměti, které lze pozorovat jako několik vláken čekajících na PAGELATCH_EX na danou stránku.

Povolením možnosti indexu OPTIMIZE_FOR_SEQUENTIAL_KEY povolíte optimalizaci v databázovém stroji, která pomáhá zlepšit propustnost vkládání do indexu s vysokou souběžností. Je určen pro indexy, které mají sekvenční klíč, a proto jsou náchylné k závěru kolize vložení poslední stránky, ale může také pomoci s indexy, které mají aktivní místa v jiných oblastech struktury indexu B-Tree.

Poznámka

Dokumentace používá termín B-tree obecně v odkazu na indexy. V indexech rowstore databázový stroj implementuje strom B+. To neplatí pro indexy columnstore ani indexy v tabulkách optimalizovaných pro paměť. Další informace najdete v SQL Serveru a architektuře indexu Azure SQL a průvodci návrhem.

Zobrazení informací indexu

Pokud chcete vrátit informace o indexech, můžete použít zobrazení katalogu, systémové funkce a systémové uložené procedury.

Komprese dat

Komprese dat je popsána v tématu Komprese dat. Následující klíčové body je třeba vzít v úvahu:

  • Komprese umožňuje ukládání více řádků na stránce, ale nemění maximální velikost řádku.
  • Jiné než listové stránky indexu nejsou komprimované, ale dají se komprimovat řádky.
  • Každý neclusterovaný index má individuální nastavení komprese a nedědí nastavení komprese podkladové tabulky.
  • Při vytvoření clusterovaného indexu v haldě clusterovaný index zdědí stav komprese haldy, pokud není zadán alternativní stav komprese.

Následující omezení platí pro dělené indexy:

  • Pokud tabulka obsahuje nerovné indexy, nemůžete změnit nastavení komprese jednoho oddílu.
  • Syntaxe ALTER INDEX <index> ... REBUILD PARTITION ... znovu sestaví zadaný oddíl indexu.
  • Syntaxe ALTER INDEX <index> ... REBUILD WITH ... znovu sestaví všechny oddíly indexu.

Pokud chcete vyhodnotit, jak změna stavu komprese ovlivní tabulku, index nebo oddíl, použijte sp_estimate_data_compression_savings uloženou proceduru.

Komprese XML

platí pro: SQL Server 2022 (16.x) a novější verze, Azure SQL Database a Azure SQL Managed Instance.

Mnoho stejných aspektů komprese dat platí pro kompresi XML. Měli byste také vědět o následujících aspektech:

  • Při zadání seznamu oddílů lze u jednotlivých oddílů povolit kompresi XML. Pokud není zadaný seznam oddílů, jsou všechny oddíly nastavené tak, aby používaly kompresi XML. Při vytvoření tabulky nebo indexu je komprese dat XML zakázána, pokud není zadáno jinak. Při úpravě tabulky se stávající komprese zachová, pokud není zadáno jinak.
  • Pokud zadáte seznam oddílů nebo oddíl, který je mimo rozsah, vygeneruje se chyba.
  • Při vytvoření clusterovaného indexu v haldě clusterovaný index zdědí stav komprese XML haldy, pokud není zadána alternativní možnost komprese.
  • Změna nastavení komprese XML haldy vyžaduje, aby byly všechny neclusterované indexy v tabulce znovu sestaveny tak, aby měly ukazatele na nová umístění řádků v haldě.
  • Kompresi XML můžete povolit nebo zakázat online nebo offline. Povolení komprese haldy je jedno vlákno pro online operaci.
  • Pokud chcete určit stav komprese XML oddílů v dělené tabulce, zadejte dotaz na sloupec xml_compression zobrazení katalogu sys.partitions.

Dovolení

Vyžaduje ALTER oprávnění k tabulce nebo zobrazení nebo členství v db_ddladmin pevné databázové roli.

Omezení a omezení

V systému Azure Synapse Analytics a Analytics Platform System (PDW) nemůžete vytvářet:

  • Clusterovaný nebo neclusterovaný index rowstore v tabulce datového skladu, pokud již index columnstore existuje. Toto chování se liší od SQL Serveru SMP, který umožňuje, aby indexy rowstore i columnstore existovaly společně ve stejné tabulce.
  • V zobrazení nelze vytvořit index.

Metadata

Chcete-li zobrazit informace o existujících indexech, můžete dotazovat sys.indexes zobrazení katalogu.

Poznámky k verzi

SQL Database nepodporuje možnosti skupiny souborů a streamu souborů.

Příklady: Všechny verze. Používá databázi AdventureWorks.

A. Vytvoření jednoduchého neclusterovaného indexu rowstore

Následující příklady vytvoří neclusterovaný index ve sloupci VendorID tabulky 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. Vytvoření jednoduchého neclusterovaného složeného indexu rowstore

Následující příklad vytvoří neclusterovaný složený index na SalesQuota a SalesYTD sloupce tabulky Sales.SalesPerson.

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

C. Vytvoření indexu v tabulce v jiné databázi

Následující příklad vytvoří clusterovaný index ve sloupci VendorID tabulky ProductVendor v databázi Purchasing.

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

D. Přidání sloupce do indexu

Následující příklad vytvoří index IX_FF se dvěma sloupci z dbo. Tabulka FactFinance. Další příkaz znovu sestaví index s jedním dalším sloupcem a zachová existující název.

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);

Příklady: SQL Server, Azure SQL Database

E. Vytvoření jedinečného neclusterovaného indexu

Následující příklad vytvoří jedinečný neclusterovaný index ve sloupci Name tabulky Production.UnitMeasure v AdventureWorks2022 databázi. Index vynutí jedinečnost dat vložených do sloupce Name.

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

Následující dotaz testuje omezení jedinečnosti tím, že se pokusí vložit řádek se stejnou hodnotou jako v existujícím řádku.

-- 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());

Výsledná chybová zpráva:

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. Použití možnosti IGNORE_DUP_KEY

Následující příklad ukazuje účinek IGNORE_DUP_KEY možnost vložením více řádků do dočasné tabulky nejprve s možností nastavenou na ON a znovu s možností nastavenou na OFF. Do tabulky #Test se vloží jeden řádek, který záměrně způsobí duplicitní hodnotu při spuštění druhého víceřádkového příkazu INSERT. Počet řádků v tabulce vrátí počet vložených řádků.

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

Tady jsou výsledky druhého příkazu INSERT.

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

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

Všimněte si, že řádky vložené z tabulky Production.UnitMeasure, které neporušovaly omezení jedinečnosti, byly úspěšně vloženy. Bylo vydáno upozornění a duplicitní řádek ignorován, ale celá transakce nebyla vrácena zpět.

Stejné příkazy se spustí znovu, ale s IGNORE_DUP_KEY nastaveným na 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

Tady jsou výsledky druhého příkazu 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

Všimněte si, že do tabulky Production.UnitMeasure nebyly vloženy žádné řádky z tabulky, i když omezení indexu UNIQUE porušilo pouze jeden řádek v tabulce.

G. Použití DROP_EXISTING k vyřazení a opětovnému vytvoření indexu

Následující příklad zahodí a znovu vytvoří existující index ve sloupci ProductID tabulky Production.WorkOrder v AdventureWorks2022 databázi pomocí možnosti DROP_EXISTING. Jsou také nastaveny možnosti FILLFACTOR a PAD_INDEX.

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

H. Vytvoření indexu v zobrazení

Následující příklad vytvoří zobrazení a index v tomto zobrazení. Součástí jsou dva dotazy, které používají indexované zobrazení.

-- 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

Já. Vytvoření indexu se zahrnutými (neklíčovými) sloupci

Následující příklad vytvoří neclusterovaný index s jedním klíčovým sloupcem (PostalCode) a čtyřmi neklíčovými sloupci (AddressLine1, AddressLine2, City, StateProvinceID). Dotaz, na který se vztahuje index, následuje. Pokud chcete zobrazit index vybraný optimalizátorem dotazů, v nabídce Query v aplikaci SQL Server Management Studio vyberte Zobrazit skutečný plán provádění před spuštěním dotazu.

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. Vytvoření děleného indexu

Následující příklad vytvoří neclusterovaný dělený index na TransactionsPS1, existující schéma oddílů v AdventureWorks2022 databázi. Tento příklad předpokládá, že se nainstalovala ukázka děleného indexu.

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

K. Vytvoření filtrovaného indexu

Následující příklad vytvoří filtrovaný index v tabulce Production.BillOfMaterials v databázi AdventureWorks2022. Predikát filtru může obsahovat sloupce, které nejsou klíčovými sloupci ve filtrovaném indexu. Predikát v tomto příkladu vybere pouze řádky, ve kterých je Hodnota EndDate nenulová.

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

L. Vytvoření komprimovaného indexu

Následující příklad vytvoří index pro tabulku, která není součástí, pomocí komprese řádků.

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

Následující příklad vytvoří index pro dělenou tabulku pomocí komprese řádků ve všech oddílech indexu.

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

Následující příklad vytvoří index v dělené tabulce pomocí komprese stránky na oddílu 1 komprese indexu a řádku u oddílů 2 prostřednictvím 4 indexu.

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. Vytvoření indexu s kompresí XML

platí pro: SQL Server 2022 (16.x) a novější verze, Azure SQL Database a Azure SQL Managed Instance.

Následující příklad vytvoří index u tabulky, která není součástí, pomocí komprese XML. Nejméně jeden sloupec v indexu musí být datový typ xml.

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

Následující příklad vytvoří index pro dělenou tabulku pomocí komprese XML pro všechny oddíly indexu.

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

N. Vytvoření, obnovení, pozastavení a přerušení obnovovatelných operací indexu

platí pro: SQL Server (počínaje SQL Serverem 2019 (15.x)) a Azure SQL Database

-- 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 s různými možnostmi uzamčení s nízkou prioritou

Následující příklady používají možnost WAIT_AT_LOW_PRIORITY k určení různých strategií pro řešení blokování.

--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

Následující příklad používá možnost RESUMABLE a určuje dvě MAX_DURATION hodnoty, první platí pro ABORT_AFTER_WAIT možnost, druhá platí pro RESUMABLE možnost.

--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);

Příklady: Azure Synapse Analytics a Analytický platformový systém (PDW)

P. Základní syntaxe

Vytvoření, obnovení, pozastavení a přerušení obnovovatelných operací indexu

platí pro: SQL Server (počínaje SQL Serverem 2019 (15.x)) a Azure SQL Database

-- 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;

Q. Vytvoření neclusterovaného indexu v tabulce v aktuální databázi

Následující příklad vytvoří neclusterovaný index ve sloupci VendorID tabulky ProductVendor.

CREATE INDEX IX_ProductVendor_VendorID
  ON ProductVendor (VendorID);

R. Vytvoření clusterovaného indexu v tabulce v jiné databázi

Následující příklad vytvoří neclusterovaný index ve sloupci VendorID tabulky ProductVendor v Purchasing databázi.

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

S. Vytvoření uspořádaného clusterovaného indexu v tabulce

Následující příklad vytvoří uspořádaný clusterovaný index ve sloupcích c1 a c2 tabulky T1 v databázi MyDB.

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

T. Převod CCI na uspořádaný clusterovaný index v tabulce

Následující příklad převede existující clusterovaný index columnstore na uspořádaný clusterovaný index columnstore s názvem MyOrderedCCI na c1 a c2 sloupce tabulky T2 v databázi MyDB.

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

Viz také