Mengindeks tabel kumpulan SQL khusus di Azure Synapse Analytics
Rekomendasi dan contoh untuk tabel pengindeksan di kumpulan SQL khusus di Azure Synapse Analytics.
Jenis indeks
Kumpulan SQL khusus menawarkan beberapa opsi pengindeksan termasuk indeks penyimpan kolom berkluster, indeks berkluster, dan indeks non-kluster, dan opsi non-indeks yang juga dikenal sebagai heap.
Untuk membuat tabel dengan indeks, lihat dokumentasi BUAT TABEL (kumpulan SQL khusus).
Indeks penyimpanan kolom berkluster
Secara default, kumpulan SQL khusus membuat indeks penyimpanan kolom berkluster ketika tidak ada opsi indeks yang ditentukan pada tabel. Tabel penyimpanan kolom berkluster menawarkan tingkat kompresi data tertinggi dan performa kueri keseluruhan terbaik. Tabel penyimpan kolom berkluster umumnya akan mengungguli indeks berkluster atau tabel susunan dan biasanya merupakan pilihan terbaik untuk tabel besar. Untuk alasan ini, penyimpan kolom berkluster adalah tempat terbaik untuk memulai ketika Anda tidak yakin tentang cara mengindeks tabel Anda.
Untuk membuat tabel penyimpanan kolom berkluster, cukup tentukan CLUSTERED COLUMNSTORE INDEX dalam klausa WITH, atau biarkan klausa WITH mati:
CREATE TABLE myTable
(
id int NOT NULL,
lastName varchar(20),
zipCode varchar(6)
)
WITH ( CLUSTERED COLUMNSTORE INDEX );
Ada beberapa skenario di mana penyimpan kolom berkluster mungkin bukan pilihan yang baik:
- Tabel penyimpan kolom berkluster tidak mendukung varchar(max), nvarchar(max), dan varbinary(max). Pertimbangkan susunan atau indeks berkluster sebagai gantinya.
- Tabel penyimpan kolom mungkin kurang efisien untuk data sementara. Pertimbangkan susunan dan bahkan mungkin tabel sementara.
- Tabel kecil dengan kurang dari 60 juta baris. Pertimbangkan tabel susunan.
Tabel susunan
Ketika Anda untuk sementara mendaratkan data di kumpulan SQL khusus, Anda mungkin menemukan bahwa menggunakan tabel susunan membuat proses keseluruhan lebih cepat. Ini karena beban ke susunan lebih cepat daripada mengindeks tabel dan dalam beberapa kasus bacaan berikutnya dapat dilakukan dari tembolokan. Jika Anda memuat data hanya untuk menggelarnya sebelum menjalankan lebih banyak transformasi, memuat tabel ke tabel susunan jauh lebih cepat daripada memuat data ke tabel penyimpan kolom berkluster. Selain itu, memuat data ke tabel sementara dimuat lebih cepat daripada memuat tabel ke penyimpanan permanen. Setelah data dimuat, Anda dapat membuat indeks dalam tabel untuk performa kueri yang lebih cepat.
Tabel penyimpan kolom berkluster mulai mencapai kompresi optimal setelah ada lebih dari 60 juta baris. Untuk tabel pencarian kecil, kurang dari 60 juta baris, pertimbangkan untuk menggunakan HEAP atau SUSUNAN atau indeks berkluster untuk performa kueri yang lebih cepat.
Untuk membuat tabel susunan, cukup tentukan SUSUNAN dalam klausa DENGAN:
CREATE TABLE myTable
(
id int NOT NULL,
lastName varchar(20),
zipCode varchar(6)
)
WITH ( HEAP );
Catatan
Jika Anda sering melakukan INSERToperasi , UPDATE, atau DELETE pada tabel tumpukan, disarankan untuk menyertakan pembangunan ulang tabel dalam jadwal pemeliharaan Anda dengan menggunakan ALTER TABLE perintah. Contohnya, ALTER TABLE [SchemaName].[TableName] REBUILD. Praktik ini berkontribusi pada pengurangan fragmentasi, yang mengakibatkan peningkatan performa selama operasi baca.
Indeks penyimpan kolom berkluster dan non-kluster
Indeks penyimpan kolom berkluster dapat mengungguli tabel penyimpan kolom berkluster ketika satu baris perlu diambil dengan cepat. Untuk kueri di mana pencarian baris tunggal atau sangat sedikit diperlukan untuk melakukan dengan kecepatan ekstrem, pertimbangkan indeks berkluster atau indeks sekunder non-kluster. Kerugian menggunakan indeks berkluster adalah bahwa hanya kueri yang menguntungkan yang menggunakan filter yang sangat selektif pada kolom indeks berkluster. Untuk meningkatkan filter pada kolom lain, indeks yang non-kluster dapat ditambahkan ke kolom lain. Namun, setiap indeks yang ditambahkan ke tabel menambahkan spasi dan waktu pemrosesan ke dimuat.
Untuk membuat tabel indeks berkluster, cukup tentukan INDEKS BERKLUSTER dalam klausa DENGAN:
CREATE TABLE myTable
(
id int NOT NULL,
lastName varchar(20),
zipCode varchar(6)
)
WITH ( CLUSTERED INDEX (id) );
Untuk menambahkan indeks non-kluster pada tabel, gunakan sintaks berikut:
CREATE INDEX zipCodeIndex ON myTable (zipCode);
Mengoptimalkan indeks penyimpanan kolom berkluster
Tabel penyimpanan kolom berkluster mengatur data ke dalam segmen. Memiliki kualitas segmen yang tinggi sangat penting untuk mencapai performa kueri yang optimal pada tabel penyimpanan kolom. Kualitas segmen dapat diukur berdasarkan jumlah baris dalam grup baris terkompresi. Kualitas segmen paling optimal di mana setidaknya ada baris 100K per grup baris terkompresi dan perolehan performa saat jumlah baris per grup baris mendekati 1.048.576 baris, yang merupakan baris terbanyak yang dapat dimuat oleh grup baris.
Tampilan di bawah ini dapat dibuat dan digunakan pada sistem Anda untuk menghitung baris rata-rata per grup baris dan mengidentifikasi indeks penyimpanAN kolom kluster sub-optimal. Kolom terakhir pada tampilan ini menghasilkan pernyataan SQL yang dapat digunakan untuk membangun kembali indeks Anda.
CREATE VIEW dbo.vColumnstoreDensity
AS
SELECT
GETDATE() AS [execution_date]
, DB_Name() AS [database_name]
, s.name AS [schema_name]
, t.name AS [table_name]
, MAX(p.partition_number) AS [table_partition_count]
, SUM(rg.[total_rows]) AS [row_count_total]
, SUM(rg.[total_rows])/COUNT(DISTINCT rg.[distribution_id]) AS [row_count_per_distribution_MAX]
, CEILING((SUM(rg.[total_rows])*1.0/COUNT(DISTINCT rg.[distribution_id]))/1048576) AS [rowgroup_per_distribution_MAX]
, SUM(CASE WHEN rg.[State] = 0 THEN 1 ELSE 0 END) AS [INVISIBLE_rowgroup_count]
, SUM(CASE WHEN rg.[State] = 0 THEN rg.[total_rows] ELSE 0 END) AS [INVISIBLE_rowgroup_rows]
, MIN(CASE WHEN rg.[State] = 0 THEN rg.[total_rows] ELSE NULL END) AS [INVISIBLE_rowgroup_rows_MIN]
, MAX(CASE WHEN rg.[State] = 0 THEN rg.[total_rows] ELSE NULL END) AS [INVISIBLE_rowgroup_rows_MAX]
, AVG(CASE WHEN rg.[State] = 0 THEN rg.[total_rows] ELSE NULL END) AS [INVISIBLE_rowgroup_rows_AVG]
, SUM(CASE WHEN rg.[State] = 1 THEN 1 ELSE 0 END) AS [OPEN_rowgroup_count]
, SUM(CASE WHEN rg.[State] = 1 THEN rg.[total_rows] ELSE 0 END) AS [OPEN_rowgroup_rows]
, MIN(CASE WHEN rg.[State] = 1 THEN rg.[total_rows] ELSE NULL END) AS [OPEN_rowgroup_rows_MIN]
, MAX(CASE WHEN rg.[State] = 1 THEN rg.[total_rows] ELSE NULL END) AS [OPEN_rowgroup_rows_MAX]
, AVG(CASE WHEN rg.[State] = 1 THEN rg.[total_rows] ELSE NULL END) AS [OPEN_rowgroup_rows_AVG]
, SUM(CASE WHEN rg.[State] = 2 THEN 1 ELSE 0 END) AS [CLOSED_rowgroup_count]
, SUM(CASE WHEN rg.[State] = 2 THEN rg.[total_rows] ELSE 0 END) AS [CLOSED_rowgroup_rows]
, MIN(CASE WHEN rg.[State] = 2 THEN rg.[total_rows] ELSE NULL END) AS [CLOSED_rowgroup_rows_MIN]
, MAX(CASE WHEN rg.[State] = 2 THEN rg.[total_rows] ELSE NULL END) AS [CLOSED_rowgroup_rows_MAX]
, AVG(CASE WHEN rg.[State] = 2 THEN rg.[total_rows] ELSE NULL END) AS [CLOSED_rowgroup_rows_AVG]
, SUM(CASE WHEN rg.[State] = 3 THEN 1 ELSE 0 END) AS [COMPRESSED_rowgroup_count]
, SUM(CASE WHEN rg.[State] = 3 THEN rg.[total_rows] ELSE 0 END) AS [COMPRESSED_rowgroup_rows]
, SUM(CASE WHEN rg.[State] = 3 THEN rg.[deleted_rows] ELSE 0 END) AS [COMPRESSED_rowgroup_rows_DELETED]
, MIN(CASE WHEN rg.[State] = 3 THEN rg.[total_rows] ELSE NULL END) AS [COMPRESSED_rowgroup_rows_MIN]
, MAX(CASE WHEN rg.[State] = 3 THEN rg.[total_rows] ELSE NULL END) AS [COMPRESSED_rowgroup_rows_MAX]
, AVG(CASE WHEN rg.[State] = 3 THEN rg.[total_rows] ELSE NULL END) AS [COMPRESSED_rowgroup_rows_AVG]
, 'ALTER INDEX ALL ON ' + s.name + '.' + t.NAME + ' REBUILD;' AS [Rebuild_Index_SQL]
FROM sys.[dm_pdw_nodes_db_column_store_row_group_physical_stats] rg
JOIN sys.[pdw_nodes_tables] nt ON rg.[object_id] = nt.[object_id]
AND rg.[pdw_node_id] = nt.[pdw_node_id]
AND rg.[distribution_id] = nt.[distribution_id]
JOIN sys.[pdw_permanent_table_mappings] mp ON nt.[name] = mp.[physical_name]
JOIN sys.[tables] t ON mp.[object_id] = t.[object_id]
JOIN sys.[schemas] s ON t.[schema_id] = s.[schema_id]
JOIN sys.[partitions] p ON P.object_id = t.object_id
GROUP BY
s.[name]
, t.[name];
Sekarang setelah Anda membuat tampilan, jalankan kueri ini untuk mengidentifikasi tabel dengan grup baris dengan kurang dari 100.000 baris. Anda mungkin ingin meningkatkan ambang batas 100.000 jika Anda mencari kualitas segmen yang lebih optimal.
SELECT *
FROM [dbo].[vColumnstoreDensity]
WHERE COMPRESSED_rowgroup_rows_AVG < 100000
OR INVISIBLE_rowgroup_rows_AVG < 100000;
Setelah menjalankan kueri, Anda dapat mulai melihat data dan menganalisis hasil Anda. Tabel ini menjelaskan bagian yang harus dicari dalam analisis grup baris Anda.
| Kolom | Cara menggunakan data ini |
|---|---|
| [table_partition_count] | Jika tabel dipartisi, maka Anda mungkin berharap untuk melihat jumlah grup baris Terbuka yang lebih tinggi. Setiap partisi dalam distribusi dapat secara teori memiliki grup baris terbuka yang terkait dengannya. Sertakan faktor ini ke dalam analisis Anda. Tabel kecil yang telah dipartisi dapat dioptimalkan dengan menghapus partisi sama sekali karena ini akan meningkatkan kompresi. |
| [row_count_total] | Jumlah baris total untuk tabel. Misalnya, Anda dapat menggunakan nilai ini untuk menghitung persentase baris dalam status terkompresi. |
| [row_count_per_distribution_MAX] | Jika semua baris didistribusikan secara merata, nilai ini akan menjadi jumlah target baris per distribusi. Bandingkan nilai ini dengan compressed_rowgroup_count. |
| [COMPRESSED_rowgroup_rows] | Jumlah total baris dalam format penyimpan kolom untuk tabel. |
| [COMPRESSED_rowgroup_rows_AVG] | Jika jumlah rata-rata baris secara signifikan kurang dari maksimum # baris untuk grup baris, maka pertimbangkan untuk menggunakan CTAS atau UBAH PENYUSUNAN ULANG INDEKS untuk mengompresi ulang data |
| [COMPRESSED_rowgroup_count] | Jumlah grup baris dalam format penyimpan kolom. Jika angka ini sangat tinggi dalam kaitannya dengan tabel, itu adalah indikator bahwa kepadatan penyimpan kolom rendah. |
| [COMPRESSED_rowgroup_rows_DELETED] | Baris dihapus secara logis dalam format penyimpan kolom. Jika angka tersebut relatif tinggi terhadap ukuran tabel, pertimbangkan untuk membuat ulang partisi atau membangun ulang indeks karena ini akan menghapusnya secara fisik. |
| [COMPRESSED_rowgroup_rows_MIN] | Gunakan ini bersama dengan kolom AVG dan MAX untuk memahami rentang nilai untuk grup baris di penyimpanan kolom Anda. Angka rendah di atas ambang batas beban (102.400 per distribusi sejajar partisi) menunjukkan bahwa pengoptimalan tersedia dalam beban data |
| [COMPRESSED_rowgroup_rows_MAX] | Seperti di atas |
| [OPEN_rowgroup_count] | Grup baris terbuka normal. Seseorang secara wajar mengharapkan satu grup baris TERBUKA per distribusi tabel (60). Angka yang berlebihan menyarankan pemuatan data di seluruh partisi. Periksa kembali strategi partisi untuk memastikan itu adalah suara |
| [OPEN_rowgroup_rows] | Setiap grup baris dapat memiliki 1.048.576 baris di dalamnya sebagai jumlah maksimum. Gunakan nilai ini untuk melihat seberapa penuh grup baris terbuka saat ini |
| [OPEN_rowgroup_rows_MIN] | Grup terbuka menunjukkan bahwa data sedang dimuat ke dalam tabel atau bahwa beban sebelumnya melampaui baris yang tersisa ke dalam grup baris ini. Gunakan kolom MIN, MAX, AVG untuk melihat berapa banyak data yang ada di grup baris OPEN. Untuk tabel kecil, dapat mencapai 100% dari semua data! Dalam hal ini UBAH PENYUSUNAN ULANG INDEKS untuk memasukkan data ke penyimpan kolom. |
| [OPEN_rowgroup_rows_MAX] | Seperti di atas |
| [OPEN_rowgroup_rows_AVG] | Seperti di atas |
| [CLOSED_rowgroup_rows] | Lihat baris grup baris tertutup sebagai pemeriksaan kewarasan. |
| [CLOSED_rowgroup_count] | Jumlah grup baris tertutup harus rendah jika ada yang terlihat sama sekali. Grup baris tertutup dapat dikonversi ke grup baris terkompresi menggunakan perintah UBAH INDEKS ... ATTUR ULANG. Namun, ini biasanya tidak diperlukan. Grup tertutup secara otomatis dikonversi ke grup baris penyimpan kolom berdasarkan proses latar belakang "penggerak tuple". |
| [CLOSED_rowgroup_rows_MIN] | Grup baris tertutup harus memiliki tingkat pengisian yang sangat tinggi. Jika tingkat pengisian untuk grup baris tertutup rendah, maka analisis lebih lanjut dari penyimpan kolom diperlukan. |
| [CLOSED_rowgroup_rows_MAX] | Seperti di atas |
| [CLOSED_rowgroup_rows_AVG] | Seperti di atas |
| [Rebuild_Index_SQL] | SQL untuk membangun ulang indeks penyimpan ulang untuk tabel |
Dampak pemeliharaan indeks
Kolom Rebuild_Index_SQL dalam vColumnstoreDensity tampilan berisi ALTER INDEX REBUILD pernyataan yang dapt digunakan untuk membangun ulang indeks Anda. Saat membangun ulang indeks, pastikan Anda mengalokasikan cukup memori untuk sesi yang membangun ulang indeks Anda. Untuk melakukan ini, tingkatkan kelas sumber daya pengguna yang memiliki izin untuk membangun kembali indeks pada tabel ini menjadi minimum yang disarankan. Misalnya, lihat Membangun ulang indeks untuk meningkatkan kualitas segmen nanti di artikel ini.
Untuk tabel dengan indeks penyimpan kolom berkluster yang diurutkan, ALTER INDEX REBUILD akan mengurutkan ulang data menggunakan tempdb. Pantau tempdb selama operasi pembangunan ulang. Jika Anda membutuhkan lebih banyak ruang tempdb, tingkatkan kumpulan database. Turunkan skala setelah pembangunan ulang indeks selesai.
Untuk tabel dengan indeks penyimpan kolom berkluster yang diurutkan, ALTER INDEX REORGANIZE tidak mengurutkan ulang data. Untuk mengurutkan ulang data, gunakan ALTER INDEX REBUILD.
Untuk informasi selengkapnya tentang indeks penyimpan kolom berkluster yang diurutkan, lihat Penyetelan performa dengan indeks penyimpan kolom yang diurutkan.
Penyebab kualitas indeks penyimpan kolom yang buruk
Jika Anda telah mengidentifikasi tabel dengan kualitas segmen yang buruk, Anda ingin mengidentifikasi akar penyebabnya. Di bawah ini adalah beberapa penyebab umum lainnya dari kualitas segmen yang buruk:
- Tekanan memori ketika indeks sedang dibangun
- Volume operasi DML yang tinggi
- Operasi beban kecil atau tetesan
- Memiliki terlalu banyak partisi
Faktor-faktor ini dapat menyebabkan indeks penyimpan kolom secara signifikan memiliki kurang dari 1 juta baris optimal per grup baris. Faktor ini juga dapat menyebabkan baris masuk ke grup baris delta alih-alih grup baris terkompresi.
Tekanan memori ketika indeks sedang dibangun
Jumlah baris per grup baris terkompresi terkait langsung dengan lebar baris dan jumlah memori yang tersedia untuk memproses grup baris. Saat baris ditulis ke tabel penyimpanan kolom di bawah tekanan memori, kualitas segmen penyimpanan kolom akan menurun. Oleh karena itu, praktik terbaik adalah memberikan sesi yang menulis ke tabel indeks penyimpan kolom Anda akses ke memori sebanyak mungkin. Karena terdapat konsekuensi antara memori dan konkurensi, panduan tentang alokasi memori yang tepat tergantung pada data di setiap baris tabel Anda, unit gudang data yang dialokasikan untuk sistem Anda, dan jumlah slot konkurensi yang dapat Anda berikan ke sesi yang menulis data ke tabel Anda.
Volume operasi DML yang tinggi
Volume tinggi operasi DML yang memperbarui dan menghapus baris dapat memperkenalkan inefisiensi ke dalam penyimpan kolom. Ini terutama berlaku ketika sebagian besar baris dalam grup baris dimodifikasi.
- Menghapus baris dari grup baris terkompresi hanya menandai baris sebagai dihapus secara logis. Baris tetap berada di grup baris terkompresi hingga partisi atau tabel dibangun kembali.
- Menyisipkan baris menambahkan baris ke tabel penyimpanan baris internal yang disebut grup baris delta. Baris yang disisipkan tidak dikonversi ke penyimpanan kolom hingga grup baris delta penuh dan ditandai sebagai tertutup. Grup baris ditutup setelah mencapai kapasitas maksimum 1.048.576 baris.
- Memperbarui baris dalam format penyimpan kolom diproses sebagai penghapusan logis lalu sisipan. Baris yang disisipkan dapat disimpan di penyimpan delta.
Pembaruan batch dan sisipkan operasi yang melebihi ambang batas massal 102.400 baris per distribusi sejajar partisi langsung ke format penyimpan kolom. Namun, dengan asumsi distribusi yang merata, Anda harus memodifikasi lebih dari 6,144 juta baris dalam satu operasi agar ini terjadi. Jika jumlah baris untuk distribusi sejajar partisi yang diberikan kurang dari 102.400 maka baris yang masuk ke penyimpan delta dan tinggal di sana hingga baris yang cukup telah disisipkan atau dimodifikasi untuk menutup grup baris atau indeks telah dibangun kembali.
Operasi beban kecil atau tetesan
Beban kecil yang mengalir ke kumpulan SQL khusus juga terkadang dikenal sebagai beban tetesan. Beban biasanya mewakili aliran data yang hampir konstan yang diserap oleh sistem. Namun, karena aliran ini hampir terus menerus volume baris tidak terlalu besar. Lebih sering daripada bukan data secara signifikan di bawah ambang batas yang diperlukan untuk beban langsung ke format penyimpan kolom.
Dalam situasi ini, sering kali lebih baik untuk mendaratkan data terlebih dahulu di penyimpanan blob Azure dan membiarkannya menumpuk sebelum memuat. Teknik ini sering dikenal sebagai micro-batching.
Memiliki terlalu banyak partisi
Hal lain yang perlu dipertimbangkan adalah dampak partisi pada tabel penyimpan kolom berkluster Anda. Sebelum partisi, kumpulan SQL khusus sudah membagi data Anda menjadi 60 database. Partisi selanjutnya membagi data Anda. Selain itu, jika Anda mempartisi data Anda, maka Anda akan ingin mempertimbangkan bahwa setiap partisi perlu memiliki 1 juta baris untuk mendapatkan manfaat dari indeks penyimpan kolom berkluster. Jika Anda mempartisi tabel Anda menjadi 100 partisi, maka tabel Anda membutuhkan setidaknya 6 miliar baris untuk mendapatkan manfaat dari indeks penyimpan kolom berkluster (60 distribusi 100 partisi 1 juta baris). Jika tabel Anda 100 partisi Anda tidak memiliki 6 miliar baris, kurangi jumlah partisi atau pertimbangkan untuk menggunakan tabel susunan sebagai gantinya.
Setelah tabel Anda dimuat dengan beberapa data, ikuti langkah-langkah di bawah ini untuk mengidentifikasi dan membangun kembali tabel dengan indeks penyimpan kolom berkluster sub-optimal.
Membangun ulang indeks untuk meningkatkan kualitas segmen
Langkah 1: Mengidentifikasi atau membuat pengguna yang menggunakan kelas sumber daya yang tepat
Salah satu cara cepat untuk segera meningkatkan kualitas segmen adalah dengan membangun kembali indeks. SQL yang dikembalikan oleh tampilan di atas mengembalikan pernyataan UBAH PENYUSUNAN ULANG INDEKS yang dapat digunakan untuk membangun kembali indeks Anda. Saat membangun ulang indeks, pastikan Anda mengalokasikan cukup memori untuk sesi yang membangun ulang indeks Anda. Untuk melakukan ini, tingkatkan kelas sumber daya pengguna yang memiliki izin untuk membangun kembali indeks pada tabel ini menjadi minimum yang disarankan.
Di bawah ini adalah contoh cara mengalokasikan lebih banyak memori kepada pengguna dengan meningkatkan kelas sumber daya mereka. Untuk bekerja dengan kelas sumber daya, lihat Kelas sumber daya untuk manajemen beban kerja.
EXEC sp_addrolemember 'xlargerc', 'LoadUser';
Langkah 2: Membangun ulang indeks penyimpan kolom berkluster dengan pengguna kelas sumber daya yang lebih tinggi
Masuk sebagai pengguna dari langkah 1 (LoadUser), yang sekarang menggunakan kelas sumber daya yang lebih tinggi, dan jalankan pernyataan UBAH INDEKS. Pastikan bahwa pengguna ini memiliki izin UBAH ke tabel tempat indeks sedang dibangun ulang. Contoh-contoh ini menunjukkan cara membangun kembali seluruh indeks penyimpan kolom atau cara membangun ulang partisi tunggal. Pada tabel besar, lebih praktis untuk membangun kembali indeks partisi tunggal pada satu waktu.
Atau, alih-alih membangun kembali indeks, Anda dapat menyalin tabel ke tabel baru menggunakan CTAS. Mana arah yang terbaik? Untuk data dalam volume besar, CTAS biasanya lebih cepat daripada UBAH INDEKS. Untuk volume data yang lebih kecil, UBAH INDEKS lebih mudah digunakan dan tidak akan mengharuskan Anda untuk menukar tabel.
-- Rebuild the entire clustered index
ALTER INDEX ALL ON [dbo].[DimProduct] REBUILD;
-- Rebuild a single partition
ALTER INDEX ALL ON [dbo].[FactInternetSales] REBUILD Partition = 5;
-- Rebuild a single partition with archival compression
ALTER INDEX ALL ON [dbo].[FactInternetSales] REBUILD Partition = 5 WITH (DATA_COMPRESSION = COLUMNSTORE_ARCHIVE);
-- Rebuild a single partition with columnstore compression
ALTER INDEX ALL ON [dbo].[FactInternetSales] REBUILD Partition = 5 WITH (DATA_COMPRESSION = COLUMNSTORE);
Membangun kembali indeks di kumpulan SQL khusus adalah operasi offline. Untuk informasi selengkapnya tentang membangun kembali indeks, lihat bagian UBAH PENYUSUNAN ULANG INDEKS di Defragmentasi Indeks Penyimpan Kolom,dan UBAH INDEKS.
Langkah 3: Verifikasi kualitas segmen penyimpan kolom berkluster telah meningkat
Jalankan ulang kueri yang mengidentifikasi tabel dengan kualitas segmen yang buruk dan memverifikasi kualitas segmen telah meningkat. Jika kualitas segmen tidak meningkat, bisa jadi baris dalam tabel Anda sangat lebar. Pertimbangkan untuk menggunakan kelas sumber daya yang lebih tinggi atau DWU saat membangun ulang indeks Anda.
Membangun ulang indeks dengan CTAS dan pengalihan partisi
Contoh ini menggunakan pernyataan CREATE TABLE AS SELECT (CTAS) dan pengalihan partisi untuk membangun kembali partisi tabel.
-- Step 1: Select the partition of data and write it out to a new table using CTAS
CREATE TABLE [dbo].[FactInternetSales_20000101_20010101]
WITH ( DISTRIBUTION = HASH([ProductKey])
, CLUSTERED COLUMNSTORE INDEX
, PARTITION ( [OrderDateKey] RANGE RIGHT FOR VALUES
(20000101,20010101
)
)
)
AS
SELECT *
FROM [dbo].[FactInternetSales]
WHERE [OrderDateKey] >= 20000101
AND [OrderDateKey] < 20010101
;
-- Step 2: Switch IN the rebuilt data with TRUNCATE_TARGET option
ALTER TABLE [dbo].[FactInternetSales_20000101_20010101] SWITCH PARTITION 2 TO [dbo].[FactInternetSales] PARTITION 2 WITH (TRUNCATE_TARGET = ON);
Untuk informasi selengkapnya tentang membuat ulang partisi menggunakan CTAS, lihat Menggunakan partisi di kumpulan SQL khusus.
Langkah berikutnya
Untuk informasi selengkapnya tentang mengembangkan tabel, lihat Mengembangkan tabel.