Fitur pemrosesan kueri cerdas secara rinci

Artikel
01/21/2024

Berlaku untuk: SQL Server Azure SQL Database Azure SQL Managed Instance

Artikel ini berisi deskripsi mendalam tentang berbagai fitur pemrosesan kueri cerdas (IQP), catatan rilis, dan detail selengkapnya. Keluarga fitur pemrosesan kueri cerdas (IQP) mencakup fitur dengan dampak luas yang meningkatkan performa beban kerja yang ada dengan upaya implementasi minimal untuk diadopsi.

Anda dapat membuat beban kerja memenuhi syarat secara otomatis untuk pemrosesan kueri cerdas dengan mengaktifkan tingkat kompatibilitas database yang berlaku untuk database. Anda dapat mengatur ini menggunakan Transact-SQL. Misalnya, untuk mengatur tingkat kompatibilitas database ke SQL Server 2022 (16.x):

ALTER DATABASE [WideWorldImportersDW] SET COMPATIBILITY_LEVEL = 160;

Untuk informasi selengkapnya tentang perubahan yang diperkenalkan dengan versi baru, lihat:

Gabungan Adaptif mode Batch

Berlaku untuk: SQL Server (Dimulai dengan SQL Server 2017 (14.x)), Azure SQL Database

Fitur Gabungan Adaptif mode batch memungkinkan pilihan metode Gabungan Hash atau Gabungan Perulangan Berlapis untuk ditangguhkan hingga setelah input pertama dipindai, dengan menggunakan satu paket cache. Operator Gabungan Adaptif menentukan ambang batas yang digunakan untuk memutuskan kapan harus beralih ke paket Nested Loops. Oleh karena itu, paket Anda dapat secara dinamis beralih ke strategi gabungan yang lebih baik selama eksekusi.

Untuk informasi selengkapnya, termasuk cara menonaktifkan gabungan Adaptif tanpa mengubah tingkat kompatibilitas, lihat Memahami gabungan Adaptif.

Eksekusi interleaved untuk MSTVF

Berlaku untuk: SQL Server (Dimulai dengan SQL Server 2017 (14.x)), Azure SQL Database

Fungsi bernilai tabel multi-pernyataan (MSTVF) adalah jenis fungsi yang ditentukan pengguna yang dapat menerima parameter, menjalankan beberapa pernyataan T-SQL, dan RETURN tabel.

Eksekusi interleaved membantu masalah performa beban kerja yang disebabkan oleh perkiraan kardinalitas tetap yang terkait dengan MSTVF. Dengan eksekusi interleaved, jumlah baris aktual dari fungsi digunakan untuk membuat keputusan rencana kueri hilir yang lebih tepat.

MSTVF memiliki tebakan kardinalitas tetap 100 yang dimulai dengan SQL Server 2014 (12.x), dan 1 untuk versi SQL Server sebelumnya.

Eksekusi interleaved mengubah batas searah antara fase pengoptimalan dan eksekusi untuk eksekusi kueri tunggal dan memungkinkan rencana untuk beradaptasi berdasarkan perkiraan kardinalitas yang direvisi. Selama pengoptimalan jika mesin database menemukan kandidat untuk eksekusi interleaved yang menggunakan fungsi bernilai tabel multi-pernyataan (MSTVF), pengoptimalan akan menjeda, menjalankan subtree yang berlaku, menangkap perkiraan kardinalitas yang akurat, dan kemudian melanjutkan pengoptimalan untuk operasi hilir.

Gambar berikut menggambarkan output Statistik Kueri Langsung, subset rencana eksekusi keseluruhan yang menunjukkan dampak perkiraan kardinalitas tetap dari MSTVF

Anda dapat melihat alur baris aktual vs. perkiraan baris. Ada tiga area penting dari rencana (alurnya dari kanan ke kiri):

Pemindaian Tabel MSTVF memiliki perkiraan tetap 100 baris. Namun, untuk contoh ini, ada 527.597 baris yang mengalir melalui Pemindaian Tabel MSTVF ini, seperti yang terlihat dalam Statistik Kueri Langsung melalui 527597 100 aktual perkiraan - sehingga perkiraan tetap secara signifikan condong.
Untuk operasi Perulangan Berlapis, hanya 100 baris yang diasumsikan dikembalikan oleh sisi luar gabungan. Mengingat tingginya jumlah baris yang benar-benar dikembalikan oleh MSTVF, Anda kemungkinan lebih baik dengan algoritma gabungan yang berbeda sama sekali.
Untuk operasi Hash Match, perhatikan simbol peringatan kecil, yang dalam hal ini menunjukkan tumpahan ke disk.

Berbeda dengan paket sebelumnya dengan rencana aktual yang dihasilkan dengan eksekusi interleaved diaktifkan:

Perhatikan bahwa pemindaian tabel MSTVF sekarang mencerminkan perkiraan kardinalitas yang akurat. Perhatikan juga urutan ulang pemindaian tabel ini dan operasi lainnya.
Dan mengenai algoritma gabungan, kami telah beralih dari operasi Perulangan Berlapis ke operasi Hash Match sebagai gantinya, yang lebih optimal mengingat banyaknya baris yang terlibat.
Perhatikan juga bahwa kita tidak lagi memiliki peringatan tumpahan, karena kita memberikan lebih banyak memori berdasarkan jumlah baris benar yang mengalir dari pemindaian tabel MSTVF.

Pernyataan yang memenuhi syarat eksekusi interleaved

Pernyataan referensi MSTVF dalam eksekusi interleaved saat ini harus baca-saja dan bukan bagian dari operasi modifikasi data. Selain itu, MSTVF tidak memenuhi syarat untuk eksekusi interleaved jika mereka tidak menggunakan konstanta runtime.

Manfaat eksekusi interleaved

Secara umum, semakin tinggi ke condong antara perkiraan vs. jumlah baris aktual, ditambah dengan jumlah operasi rencana hilir, semakin besar dampak performa.

Secara umum, kueri manfaat eksekusi yang saling terkait di mana:

Ada ke condong besar antara perkiraan vs. jumlah baris aktual untuk tataan hasil menengah (dalam hal ini, MSTVF).
Dan kueri keseluruhan sensitif terhadap perubahan ukuran hasil perantara. Ini biasanya terjadi ketika ada pohon kompleks di atas subtree tersebut dalam rencana kueri. SELECT * Sederhana dari MSTVF tidak akan mendapat manfaat dari eksekusi yang saling berhubungan.

Overhead eksekusi interleaved

Overhead harus minimal ke tidak ada. MSTVF sudah diwujudkan sebelum pengenalan eksekusi interleaved, namun perbedaannya adalah sekarang kita mengizinkan pengoptimalan yang ditangguhkan dan kemudian menggunakan perkiraan kardinalitas dari kumpulan baris materialisasi. Seperti halnya rencana apa pun yang memengaruhi perubahan, beberapa rencana dapat berubah sewaktu-waktu sehingga dengan kardinalitas yang lebih baik untuk subtree, kita mendapatkan rencana yang lebih buruk untuk kueri secara keseluruhan. Mitigasi dapat mencakup mengembalikan tingkat kompatibilitas atau menggunakan Penyimpanan Kueri untuk memaksa versi paket yang tidak diregresikan.

Eksekusi interleaved dan eksekusi berturut-turut

Setelah rencana eksekusi interleaved di-cache, rencana dengan perkiraan yang direvisi pada eksekusi pertama digunakan untuk eksekusi berturut-turut tanpa menginstansiasi kembali eksekusi interleaved.

Melacak aktivitas eksekusi interleaved

Anda dapat melihat atribut penggunaan dalam rencana eksekusi kueri aktual:

Atribut Rencana Eksekusi	Deskripsi
ContainsInterleavedExecutionCandidates	Berlaku untuk simpul QueryPlan . Jika benar, berarti rencana tersebut berisi kandidat eksekusi yang saling berhubungan.
IsInterleavedExecuted	Atribut elemen RuntimeInformation di bawah RelOp untuk simpul TVF. Ketika benar, berarti operasi diwujudkan sebagai bagian dari operasi eksekusi yang saling berhubungan.

Anda juga dapat melacak kejadian eksekusi interleaved melalui peristiwa yang diperluas berikut:

XEvent	Deskripsi
`interleaved_exec_status`	Peristiwa ini terjadi ketika eksekusi interleaved terjadi.
`interleaved_exec_stats_update`	Kejadian ini menjelaskan perkiraan kardinalitas yang diperbarui oleh eksekusi yang saling berhubungan.
`Interleaved_exec_disabled_reason`	Kejadian ini diaktifkan ketika kueri dengan kandidat yang mungkin untuk eksekusi interleaved sebenarnya tidak mendapatkan eksekusi interleaved.

Kueri harus dijalankan untuk memungkinkan eksekusi interleaved untuk merevisi perkiraan kardinalitas MSTVF. Namun, perkiraan rencana eksekusi masih menunjukkan kapan ada kandidat eksekusi yang saling berhubungan melalui ContainsInterleavedExecutionCandidates atribut showplan.

Penembolokan eksekusi interleaved

Jika rencana dihapus atau dikeluarkan dari cache, setelah eksekusi kueri, ada kompilasi baru yang menggunakan eksekusi interleaved. Pernyataan menggunakan OPTION (RECOMPILE) membuat rencana baru menggunakan eksekusi yang terjalin dan bukan cache.

Eksekusi interleaved dan interoperabilitas Query Store

Rencana menggunakan eksekusi interleaved dapat dipaksa. Rencananya adalah versi yang telah mengoreksi perkiraan kardinalitas berdasarkan eksekusi awal.

Menonaktifkan eksekusi interleaved tanpa mengubah tingkat kompatibilitas

Eksekusi interleaved dapat dinonaktifkan pada cakupan database atau pernyataan sambil tetap mempertahankan tingkat kompatibilitas database 140 dan yang lebih tinggi. Untuk menonaktifkan eksekusi interleaved untuk semua eksekusi kueri yang berasal dari database, jalankan hal berikut dalam konteks database yang berlaku:

-- SQL Server 2017
ALTER DATABASE SCOPED CONFIGURATION SET DISABLE_INTERLEAVED_EXECUTION_TVF = ON;

-- Starting with SQL Server 2019, and in Azure SQL Database
ALTER DATABASE SCOPED CONFIGURATION SET INTERLEAVED_EXECUTION_TVF = OFF;

Saat diaktifkan, pengaturan ini muncul sebagai diaktifkan di sys.database_scoped_configurations. Untuk mengaktifkan kembali eksekusi interleaved untuk semua eksekusi kueri yang berasal dari database, jalankan hal berikut dalam konteks database yang berlaku:

-- SQL Server 2017
ALTER DATABASE SCOPED CONFIGURATION SET DISABLE_INTERLEAVED_EXECUTION_TVF = OFF;

-- Starting with SQL Server 2019, and in Azure SQL Database
ALTER DATABASE SCOPED CONFIGURATION SET INTERLEAVED_EXECUTION_TVF = ON;

Anda juga dapat menonaktifkan eksekusi interleaved untuk kueri tertentu dengan menunjuk DISABLE_INTERLEAVED_EXECUTION_TVF sebagai petunjuk kueri USE HINT. Contohnya:

SELECT [fo].[Order Key], [fo].[Quantity], [foo].[OutlierEventQuantity]
FROM [Fact].[Order] AS [fo]
INNER JOIN [Fact].[WhatIfOutlierEventQuantity]('Mild Recession',
                            '1-01-2013',
                            '10-15-2014') AS [foo] ON [fo].[Order Key] = [foo].[Order Key]
                            AND [fo].[City Key] = [foo].[City Key]
                            AND [fo].[Customer Key] = [foo].[Customer Key]
                            AND [fo].[Stock Item Key] = [foo].[Stock Item Key]
                            AND [fo].[Order Date Key] = [foo].[Order Date Key]
                            AND [fo].[Picked Date Key] = [foo].[Picked Date Key]
                            AND [fo].[Salesperson Key] = [foo].[Salesperson Key]
                            AND [fo].[Picker Key] = [foo].[Picker Key]
OPTION (USE HINT('DISABLE_INTERLEAVED_EXECUTION_TVF'));

Petunjuk kueri USE HINT lebih diutamakan daripada konfigurasi cakupan database atau pengaturan bendera pelacakan.

Inlining UDF skalar

Berlaku untuk: SQL Server (Dimulai dengan SQL Server 2019 (15.x)), Azure SQL Database

Inlining UDF skalar secara otomatis mengubah UDF skalar menjadi ekspresi relasional. Ini menyematkannya dalam kueri SQL panggilan. Transformasi ini meningkatkan performa beban kerja yang memanfaatkan UDF skalar. Scalar UDF inlining memfasilitasi pengoptimalan operasi berbasis biaya di dalam UDF. Hasilnya efisien, berorientasi pada set, dan paralel alih-alih rencana eksekusi serial yang tidak efisien, berulang. Fitur ini diaktifkan secara default di bawah tingkat kompatibilitas database 150 atau lebih tinggi.

Untuk informasi selengkapnya, lihat Scalar UDF inlining.

Kompilasi yang ditangguhkan variabel tabel

Berlaku untuk: SQL Server (Dimulai dengan SQL Server 2019 (15.x)), Azure SQL Database

Kompilasi yang ditangguhkan variabel tabel meningkatkan kualitas rencana dan performa keseluruhan untuk kueri yang mereferensikan variabel tabel. Selama pengoptimalan dan kompilasi rencana awal, fitur ini menyebarluaskan perkiraan kardinalitas yang didasarkan pada jumlah baris variabel tabel aktual. Informasi jumlah baris yang tepat ini kemudian akan digunakan untuk mengoptimalkan operasi rencana hilir.

Dengan kompilasi yang ditangguhkan variabel tabel, kompilasi pernyataan yang mereferensikan variabel tabel ditangguhkan hingga eksekusi pernyataan aktual pertama. Perilaku kompilasi yang ditangguhkan ini identik dengan perilaku tabel sementara. Perubahan ini menghasilkan penggunaan kardinalitas aktual alih-alih tebakan satu baris asli.

Untuk mengaktifkan kompilasi yang ditangguhkan variabel tabel, aktifkan tingkat kompatibilitas database 150 atau lebih tinggi untuk database yang Anda sambungkan saat kueri berjalan.

Kompilasi yang ditangguhkan variabel tabel tidak mengubah karakteristik variabel tabel lainnya. Misalnya, fitur ini tidak menambahkan statistik kolom ke variabel tabel.

Kompilasi yang ditangguhkan variabel tabel tidak meningkatkan frekuensi kompilasi ulang. Sebaliknya, itu bergeser di mana kompilasi awal terjadi. Rencana cache yang dihasilkan berdasarkan jumlah baris variabel tabel kompilasi awal yang ditangguhkan. Paket yang di-cache digunakan kembali oleh kueri berturut-turut. Ini digunakan kembali sampai rencana dikeluarkan atau dikompresi ulang.

Jumlah baris variabel tabel yang digunakan untuk kompilasi paket awal mewakili nilai umum mungkin berbeda dari tebakan jumlah baris tetap. Jika berbeda, operasi hilir akan mendapat manfaat. Performa mungkin tidak ditingkatkan oleh fitur ini jika jumlah baris variabel tabel bervariasi secara signifikan di seluruh eksekusi.

Menonaktifkan kompilasi yang ditangguhkan variabel tabel tanpa mengubah tingkat kompatibilitas

Nonaktifkan kompilasi yang ditangguhkan variabel tabel pada database atau cakupan pernyataan sambil tetap mempertahankan tingkat kompatibilitas database 150 dan yang lebih tinggi. Untuk menonaktifkan kompilasi yang ditangguhkan variabel tabel untuk semua eksekusi kueri yang berasal dari database, jalankan contoh berikut dalam konteks database yang berlaku:

ALTER DATABASE SCOPED CONFIGURATION SET DEFERRED_COMPILATION_TV = OFF;

Untuk mengaktifkan kembali kompilasi yang ditangguhkan variabel tabel untuk semua eksekusi kueri yang berasal dari database, jalankan contoh berikut dalam konteks database yang berlaku:

ALTER DATABASE SCOPED CONFIGURATION SET DEFERRED_COMPILATION_TV = ON;

Anda juga dapat menonaktifkan kompilasi yang ditangguhkan variabel tabel untuk kueri tertentu dengan menetapkan DISABLE_DEFERRED_COMPILATION_TV sebagai petunjuk kueri USE HINT. Contohnya:

DECLARE @LINEITEMS TABLE 
    (L_OrderKey INT NOT NULL,
     L_Quantity INT NOT NULL
    );

INSERT @LINEITEMS
SELECT L_OrderKey, L_Quantity
FROM dbo.lineitem
WHERE L_Quantity = 5;

SELECT O_OrderKey,
    O_CustKey,
    O_OrderStatus,
    L_QUANTITY
FROM    
    ORDERS,
    @LINEITEMS
WHERE    O_ORDERKEY    =    L_ORDERKEY
    AND O_OrderStatus = 'O'
OPTION (USE HINT('DISABLE_DEFERRED_COMPILATION_TV'));

Pengoptimalan Rencana Sensitivitas Parameter

Berlaku untuk: SQL Server 2022 (16.x) Azure SQL Database Azure SQL Managed Instance

Pengoptimalan Parameter Sensitivity Plan (PSP) adalah bagian dari rangkaian fitur pemrosesan kueri cerdas. Ini membahas skenario di mana satu rencana cache untuk kueri berparameter tidak optimal untuk semua kemungkinan nilai parameter masuk. Ini adalah kasus dengan distribusi data nonuniform.

Untuk informasi selengkapnya tentang pengoptimalan PSP, lihat Pengoptimalan Paket Sensitif Parameter.
Untuk informasi selengkapnya tentang parameterisasi dan sensitivitas parameter, lihat Sensitivitas Parameter dan Parameter dan Penggunaan Kembali Rencana Eksekusi.

Perkiraan pemrosesan kueri

Perkiraan pemrosesan kueri adalah keluarga fitur baru. Ini menggabungkan di seluruh himpunan data besar di mana responsivitas lebih penting daripada presisi absolut. Contohnya adalah menghitung COUNT(DISTINCT()) di seluruh 10 miliar baris, untuk ditampilkan di dasbor. Dalam hal ini, presisi absolut tidak penting, tetapi responsivitas sangat penting.

Perkiraan Hitungan Berbeda

Berlaku untuk: SQL Server (Dimulai dengan SQL Server 2019 (15.x)), Azure SQL Database

Fungsi agregat APPROX_COUNT_DISTINCT baru mengembalikan perkiraan jumlah nilai non-null unik dalam grup.

Fitur ini tersedia dimulai dengan SQL Server 2019 (15.x), terlepas dari tingkat kompatibilitasnya.

Untuk informasi selengkapnya, lihat APPROX_COUNT_DISTINCT (Transact-SQL).

Perkiraan Persentil

Berlaku untuk: SQL Server (Dimulai dengan SQL Server 2022 (16.x)), Azure SQL Database

Fungsi agregat ini menghitung persentil untuk himpunan data besar dengan batas kesalahan berbasis peringkat yang dapat diterima untuk membantu membuat keputusan cepat dengan menggunakan perkiraan fungsi agregat persentil.

Untuk informasi selengkapnya, lihat APPROX_PERCENTILE_DISC (Transact-SQL) dan APPROX_PERCENTILE_CONT (Transact-SQL)

Mode batch di rowstore

Berlaku untuk: SQL Server (Dimulai dengan SQL Server 2019 (15.x)), Azure SQL Database

Mode batch pada rowstore memungkinkan eksekusi mode batch untuk beban kerja analitik tanpa memerlukan indeks penyimpan kolom. Fitur ini mendukung eksekusi mode batch dan filter bitmap untuk timbunan pada disk dan indeks pohon B. Mode batch pada rowstore memungkinkan dukungan untuk semua operator yang diaktifkan mode batch yang ada.

Catatan

Dokumentasi menggunakan istilah pohon B umumnya dalam referensi ke indeks. Dalam indeks rowstore, Mesin Database mengimplementasikan pohon B+. Ini tidak berlaku untuk indeks penyimpan kolom atau indeks pada tabel yang dioptimalkan memori. Untuk informasi selengkapnya, lihat panduan arsitektur dan desain indeks SQL Server dan Azure SQL.

Gambaran umum eksekusi mode batch

SQL Server 2012 (11.x) memperkenalkan fitur baru untuk mempercepat beban kerja analitik: indeks penyimpan kolom. Kasus penggunaan dan performa indeks penyimpan kolom meningkat di setiap rilis SQL Server berikutnya. Membuat indeks penyimpan kolom pada tabel dapat meningkatkan performa untuk beban kerja analitis. Namun, ada dua set teknologi yang terkait tetapi berbeda:

Dengan indeks penyimpan kolom, kueri analitik hanya mengakses data di kolom yang mereka butuhkan. Pemadatan halaman dalam format penyimpan kolom juga lebih efektif daripada kompresi dalam indeks rowstore tradisional.
Dengan pemrosesan mode batch, operator kueri memproses data dengan lebih efisien. Mereka bekerja pada batch baris alih-alih satu baris pada satu waktu. Banyak peningkatan skalabilitas lainnya terkait dengan pemrosesan mode batch. Untuk informasi selengkapnya tentang mode batch, lihat Mode eksekusi.

Dua set fitur bekerja sama untuk meningkatkan input/output (I/O) dan pemanfaatan CPU:

Dengan menggunakan indeks penyimpan kolom, lebih banyak data Anda cocok dalam memori. Itu mengurangi beban kerja I/O.
Pemrosesan mode batch menggunakan CPU lebih efisien.

Kedua teknologi tersebut saling memanfaatkan jika memungkinkan. Misalnya, agregat mode batch dapat dievaluasi sebagai bagian dari pemindaian indeks penyimpan kolom. Juga data penyimpan kolom yang dikompresi diproses dengan menggunakan pengodean panjang eksekusi jauh lebih efisien dengan gabungan mode batch dan agregat mode batch.

Namun, penting untuk dipahami bahwa kedua fitur tersebut independen:

Anda bisa mendapatkan paket mode baris yang menggunakan indeks penyimpan kolom.
Anda bisa mendapatkan paket mode batch yang hanya menggunakan indeks rowstore.

Anda biasanya mendapatkan hasil terbaik saat menggunakan dua fitur tersebut bersama-sama. Sebelum SQL Server 2019 (15.x), pengoptimal kueri SQL Server mempertimbangkan pemrosesan mode batch hanya untuk kueri yang melibatkan setidaknya satu tabel dengan indeks penyimpan kolom.

Indeks penyimpan kolom mungkin tidak sesuai untuk beberapa aplikasi. Aplikasi mungkin menggunakan beberapa fitur lain yang tidak didukung dengan indeks penyimpan kolom. Misalnya, modifikasi di tempat tidak kompatibel dengan kompresi penyimpan kolom. Oleh karena itu, pemicu tidak didukung pada tabel dengan indeks penyimpan kolom berkluster. Lebih penting lagi, indeks penyimpan kolom menambahkan overhead untuk pernyataan DELETE dan UPDATE .

Untuk beberapa beban kerja analitik transaksional hibrid, overhead beban kerja transaksional melebihi manfaat yang diperoleh dari menggunakan indeks penyimpan kolom. Skenario tersebut dapat memperoleh manfaat dari peningkatan penggunaan CPU dengan menggunakan pemrosesan mode batch saja. Itulah sebabnya fitur batch-mode-on-rowstore mempertimbangkan mode batch untuk semua kueri terlepas dari jenis indeks apa yang terlibat.

Beban kerja yang mungkin mendapat manfaat dari mode batch di rowstore

Beban kerja berikut mungkin mendapat manfaat dari mode batch di rowstore:

Bagian penting dari beban kerja terdiri dari kueri analitik. Biasanya, kueri ini menggunakan operator seperti gabungan atau agregat yang memproses ratusan ribu baris atau lebih.
Beban kerja terikat CPU. Jika hambatannya adalah I/O, disarankan agar Anda mempertimbangkan indeks penyimpan kolom, jika memungkinkan.
Membuat indeks penyimpan kolom menambahkan terlalu banyak overhead ke bagian transaksi beban kerja Anda. Atau, membuat indeks penyimpan kolom tidak layak karena aplikasi Anda bergantung pada fitur yang belum didukung dengan indeks penyimpan kolom.

Catatan

Mode batch pada rowstore hanya membantu dengan mengurangi konsumsi CPU. Jika hambatan Anda terkait I/O, dan data belum di-cache (cache "dingin"), mode batch di rowstore tidak akan meningkatkan waktu kueri yang berlalu. Demikian pula, jika tidak ada memori yang cukup pada komputer untuk menyimpan semua data, peningkatan performa tidak mungkin terjadi.

Perubahan apa dengan mode batch pada rowstore?

Mode batch pada rowstore memerlukan database ke tingkat kompatibilitas 150.

Bahkan jika kueri tidak mengakses tabel apa pun dengan indeks penyimpan kolom, prosesor kueri menggunakan heuristik untuk memutuskan apakah akan mempertimbangkan mode batch. Heuristik terdiri dari pemeriksaan ini:

Pemeriksaan awal ukuran tabel, operator yang digunakan, dan perkiraan kardinalitas dalam kueri input.
Titik pemeriksaan tambahan, karena pengoptimal menemukan paket baru yang lebih murah untuk kueri. Jika rencana alternatif ini tidak menggunakan mode batch secara signifikan, pengoptimal berhenti menjelajahi alternatif mode batch.

Jika mode batch pada rowstore digunakan, Anda akan melihat mode eksekusi aktual sebagai mode batch dalam rencana kueri. Operator pemindaian menggunakan mode batch untuk tumpukan pada disk dan indeks pohon B. Pemindaian mode batch ini dapat mengevaluasi filter bitmap mode batch. Anda mungkin juga melihat operator mode batch lainnya dalam paket. Contohnya adalah gabungan hash, agregat berbasis hash, pengurutan, agregat jendela, filter, perangkaian, dan operator skalar komputasi.

Keterangan

Paket kueri tidak selalu menggunakan mode batch. Pengoptimal Kueri mungkin memutuskan bahwa mode batch tidak bermanfaat untuk kueri.

Ruang pencarian Pengoptimal Kueri berubah. Jadi, jika Anda mendapatkan paket mode baris, itu mungkin tidak sama dengan paket yang Anda dapatkan di tingkat kompatibilitas yang lebih rendah. Dan jika Anda mendapatkan paket mode batch, itu mungkin tidak sama dengan paket yang Anda dapatkan dengan indeks penyimpan kolom.

Paket mungkin juga berubah untuk kueri yang mencampur indeks penyimpan kolom dan rowstore karena pemindaian rowstore mode batch baru.

Ada batasan saat ini untuk mode batch baru pada pemindaian rowstore:

Ini tidak akan dimulai untuk tabel OLTP dalam memori atau untuk indeks apa pun selain tumpukan pada disk dan pohon B.
Ini juga tidak akan menendang jika kolom objek besar (LOB) diambil atau difilter. Batasan ini mencakup kumpulan kolom jarang dan kolom XML.

Ada kueri yang tidak digunakan mode batch bahkan dengan indeks penyimpan kolom. Contohnya adalah kueri yang melibatkan kursor. Pengecualian yang sama ini juga diperluas ke mode batch di rowstore.

Mengonfigurasi mode batch pada rowstore

Konfigurasi BATCH_MODE_ON_ROWSTORE cakupan database aktif secara default.

Anda dapat menonaktifkan mode batch pada rowstore tanpa mengubah tingkat kompatibilitas database:

-- Disabling batch mode on rowstore
ALTER DATABASE SCOPED CONFIGURATION SET BATCH_MODE_ON_ROWSTORE = OFF;

-- Enabling batch mode on rowstore
ALTER DATABASE SCOPED CONFIGURATION SET BATCH_MODE_ON_ROWSTORE = ON;

Anda dapat menonaktifkan mode batch di rowstore melalui konfigurasi cakupan database. Tetapi Anda masih bisa mengambil alih pengaturan di tingkat kueri dengan menggunakan ALLOW_BATCH_MODE petunjuk kueri. Contoh berikut memungkinkan mode batch pada rowstore bahkan dengan fitur dinonaktifkan melalui konfigurasi terlingkup database:

SELECT [Tax Rate], [Lineage Key], [Salesperson Key], SUM(Quantity) AS SUM_QTY, SUM([Unit Price]) AS SUM_BASE_PRICE, COUNT(*) AS COUNT_ORDER
FROM Fact.OrderHistoryExtended
WHERE [Order Date Key]<=DATEADD(dd, -73, '2015-11-13')
GROUP BY [Tax Rate], [Lineage Key], [Salesperson Key]
ORDER BY [Tax Rate], [Lineage Key], [Salesperson Key]
OPTION(RECOMPILE, USE HINT('ALLOW_BATCH_MODE'));

Anda juga dapat menonaktifkan mode batch pada rowstore untuk kueri tertentu dengan menggunakan DISALLOW_BATCH_MODE petunjuk kueri. Lihat contoh berikut:

SELECT [Tax Rate], [Lineage Key], [Salesperson Key], SUM(Quantity) AS SUM_QTY, SUM([Unit Price]) AS SUM_BASE_PRICE, COUNT(*) AS COUNT_ORDER
FROM Fact.OrderHistoryExtended
WHERE [Order Date Key]<=DATEADD(dd, -73, '2015-11-13')
GROUP BY [Tax Rate], [Lineage Key], [Salesperson Key]
ORDER BY [Tax Rate], [Lineage Key], [Salesperson Key]
OPTION(RECOMPILE, USE HINT('DISALLOW_BATCH_MODE'));

Fitur umpan balik pemrosesan kueri

Fitur umpan balik pemrosesan kueri adalah bagian dari keluarga fitur pemrosesan kueri Cerdas.

Umpan balik pemrosesan kueri adalah prosesor kueri di SQL Server, Azure SQL Database, dan Azure SQL Managed Instance menggunakan data historis tentang eksekusi kueri untuk memutuskan apakah kueri mungkin menerima bantuan dari satu atau beberapa perubahan ke cara dikompilasi dan dijalankan. Data performa dikumpulkan di Penyimpanan Kueri, dengan berbagai saran untuk meningkatkan eksekusi kueri. Jika berhasil, kami mempertahankan modifikasi ini ke disk dalam memori dan/atau di Penyimpanan Kueri untuk digunakan di masa mendatang. Jika saran tidak menghasilkan peningkatan yang memadai, saran akan dibuang, dan kueri terus dijalankan tanpa umpan balik tersebut.

Untuk informasi tentang fitur umpan balik pemrosesan kueri mana yang tersedia dalam rilis SQL Server yang berbeda, atau di Azure SQL Database atau Azure SQL Managed Instance, lihat Pemrosesan kueri cerdas di database SQL atau artikel berikut untuk setiap fitur umpan balik.

Umpan balik pemberian memori

Umpan balik pemberian memori telah diperkenalkan dalam gelombang selama rilis utama SQL Server sebelumnya.

Umpan balik pemberian memori mode batch

Untuk informasi tentang umpan balik pemberian memori mode Batch, kunjungi Umpan balik pemberian memori mode Batch.

Umpan balik pemberian memori mode baris

Untuk informasi tentang umpan balik pemberian memori mode baris, kunjungi Umpan balik pemberian memori mode baris.

Persentil dan persistensi mode memori memberikan umpan balik

Untuk informasi tentang persentil dan umpan balik pemberian memori mode persistensi, kunjungi Umpan balik pemberian memori mode persentil dan persistensi.

Tingkat paralelisme (DOP) umpan balik

Untuk informasi tentang umpan balik DOP, kunjungi Tingkat paralelisme (DOP) umpan balik.

Umpan balik estimasi kardinalitas (CE)

Untuk informasi tentang umpan balik CE, kunjungi Umpan balik kardinalitas (CE).

Paket yang dioptimalkan memaksa dengan Penyimpanan Kueri

Untuk informasi tentang memaksa rencana yang dioptimalkan dengan Penyimpanan Kueri, kunjungi Paket yang dioptimalkan memaksa dengan Penyimpanan Kueri.

Bagikan melalui

Fitur pemrosesan kueri cerdas secara rinci

Gabungan Adaptif mode Batch

Eksekusi interleaved untuk MSTVF

Pernyataan yang memenuhi syarat eksekusi interleaved

Manfaat eksekusi interleaved

Overhead eksekusi interleaved

Eksekusi interleaved dan eksekusi berturut-turut

Melacak aktivitas eksekusi interleaved

Penembolokan eksekusi interleaved

Eksekusi interleaved dan interoperabilitas Query Store

Menonaktifkan eksekusi interleaved tanpa mengubah tingkat kompatibilitas

Inlining UDF skalar

Kompilasi yang ditangguhkan variabel tabel

Menonaktifkan kompilasi yang ditangguhkan variabel tabel tanpa mengubah tingkat kompatibilitas

Pengoptimalan Rencana Sensitivitas Parameter

Perkiraan pemrosesan kueri

Perkiraan Hitungan Berbeda

Perkiraan Persentil

Mode batch di rowstore

Gambaran umum eksekusi mode batch

Beban kerja yang mungkin mendapat manfaat dari mode batch di rowstore

Perubahan apa dengan mode batch pada rowstore?

Keterangan

Mengonfigurasi mode batch pada rowstore

Fitur umpan balik pemrosesan kueri

Umpan balik pemberian memori

Umpan balik pemberian memori mode batch

Umpan balik pemberian memori mode baris

Persentil dan persistensi mode memori memberikan umpan balik

Tingkat paralelisme (DOP) umpan balik

Umpan balik estimasi kardinalitas (CE)

Paket yang dioptimalkan memaksa dengan Penyimpanan Kueri

Saran dan Komentar

Sumber Daya Tambahan:

Bagikan melalui

Fitur pemrosesan kueri cerdas secara rinci

Gabungan Adaptif mode Batch

Eksekusi interleaved untuk MSTVF

Pernyataan yang memenuhi syarat eksekusi interleaved

Manfaat eksekusi interleaved

Overhead eksekusi interleaved

Eksekusi interleaved dan eksekusi berturut-turut

Melacak aktivitas eksekusi interleaved

Penembolokan eksekusi interleaved

Eksekusi interleaved dan interoperabilitas Query Store

Menonaktifkan eksekusi interleaved tanpa mengubah tingkat kompatibilitas

Inlining UDF skalar

Kompilasi yang ditangguhkan variabel tabel

Menonaktifkan kompilasi yang ditangguhkan variabel tabel tanpa mengubah tingkat kompatibilitas

Pengoptimalan Rencana Sensitivitas Parameter

Perkiraan pemrosesan kueri

Perkiraan Hitungan Berbeda

Perkiraan Persentil

Mode batch di rowstore

Gambaran umum eksekusi mode batch

Beban kerja yang mungkin mendapat manfaat dari mode batch di rowstore

Perubahan apa dengan mode batch pada rowstore?

Keterangan

Mengonfigurasi mode batch pada rowstore

Fitur umpan balik pemrosesan kueri

Umpan balik pemberian memori

Umpan balik pemberian memori mode batch

Umpan balik pemberian memori mode baris

Persentil dan persistensi mode memori memberikan umpan balik

Tingkat paralelisme (DOP) umpan balik

Umpan balik estimasi kardinalitas (CE)

Paket yang dioptimalkan memaksa dengan Penyimpanan Kueri

Konten terkait

Saran dan Komentar

Sumber Daya Tambahan: