Bendera Jejak Baru untuk Memperbaiki Kinerja Variabel Tabel

Sudah lama diketahui bahwa variabel tabel dengan banyak baris dapat menjadi masalah, karena pengoptimal selalu melihatnya memiliki satu baris. Tanpa kompilasi ulang setelah variabel tabel telah diisi (sejak sebelum itu kosong), tidak ada kardinalitas untuk tabel, dan kompilasi ulang otomatis tidak terjadi karena variabel tabel bahkan tidak tunduk pada ambang kompilasi ulang. Oleh karena itu, rencana didasarkan pada kardinalitas tabel nol, bukan satu, tetapi minimum ditingkatkan menjadi satu seperti yang dijelaskan oleh Paul White (@SQL_Kiwi) dalam jawaban dba.stackexchange ini.

Cara yang biasanya kami lakukan untuk mengatasi masalah ini adalah dengan menambahkan OPTION (RECOMPILE) ke kueri yang mereferensikan variabel tabel, memaksa pengoptimal untuk memeriksa kardinalitas variabel tabel setelah diisi. Untuk menghindari kebutuhan untuk pergi dan secara manual mengubah setiap kueri untuk menambahkan petunjuk kompilasi ulang eksplisit, tanda pelacakan baru (2453) telah diperkenalkan di SQL Server 2012 Paket Layanan 2 dan Pembaruan Kumulatif SQL Server 2014 #3:

KB #2952444 :MEMPERBAIKI:Performa buruk saat Anda menggunakan variabel tabel di SQL Server 2012 atau SQL Server 2014

Saat bendera pelacakan 2453 aktif, pengoptimal dapat memperoleh gambaran kardinalitas tabel yang akurat setelah variabel tabel dibuat. Ini bisa menjadi A Good Thing™ untuk banyak pertanyaan, tetapi mungkin tidak semua, dan Anda harus mengetahui cara kerjanya yang berbeda dari OPTION (RECOMPILE) . Terutama, optimasi penyematan parameter yang dibicarakan oleh Paul White dalam posting ini terjadi di bawah OPTION (RECOMPILE) , tetapi tidak di bawah tanda jejak baru ini.

Tes Sederhana

Tes awal saya terdiri dari hanya mengisi variabel tabel dan memilih darinya; ini menghasilkan perkiraan jumlah baris 1. Ini adalah tes yang saya jalankan (dan saya menambahkan petunjuk kompilasi ulang untuk membandingkan):

DBCC TRACEON(2453);
 
DECLARE @t TABLE(id INT PRIMARY KEY, name SYSNAME NOT NULL UNIQUE);
 
INSERT @t SELECT TOP (1000) [object_id], name FROM sys.all_objects;
 
SELECT t.id, t.name
  FROM @t AS t;
 
SELECT t.id, t.name
  FROM @t AS t OPTION (RECOMPILE);
 
DBCC TRACEOFF(2453);

Menggunakan SQL Sentry Plan Explorer, kita dapat melihat bahwa rencana grafis untuk kedua kueri dalam kasus ini identik, mungkin setidaknya sebagian karena ini secara harfiah merupakan rencana sepele:

Rencana grafis untuk pemindaian indeks sepele terhadap @t

Namun, perkiraannya tidak sama. Meskipun tanda jejak diaktifkan, kami masih mendapatkan perkiraan 1 yang keluar dari pemindaian indeks jika kami tidak menggunakan petunjuk kompilasi ulang:

Membandingkan perkiraan untuk rencana sepele dalam kisi pernyataan

Membandingkan perkiraan antara tanda jejak (kiri) dan kompilasi ulang (kanan)

Jika Anda pernah berada di sekitar saya secara langsung, Anda mungkin dapat membayangkan wajah yang saya buat saat ini. Saya yakin bahwa artikel KB mencantumkan nomor tanda jejak yang salah, atau bahwa saya memerlukan pengaturan lain yang diaktifkan agar benar-benar aktif.

Benjamin Nevarez (@BenjaminNevarez) dengan cepat menunjukkan kepada saya bahwa saya perlu melihat lebih dekat pada artikel KB "Bugs yang diperbaiki di SQL Server 2012 Service Pack 2". Meskipun mereka telah mengaburkan teks di balik peluru tersembunyi di bawah Sorotan> Mesin Relasional, artikel daftar perbaikan melakukan pekerjaan yang sedikit lebih baik dalam menggambarkan perilaku tanda jejak daripada artikel asli (penekanan milik saya):

Jadi akan tampak dari deskripsi ini bahwa tanda jejak hanya dimaksudkan untuk mengatasi masalah ketika variabel tabel berpartisipasi dalam gabungan. (Mengapa perbedaan itu tidak dibuat dalam artikel aslinya, saya tidak tahu.) Tetapi itu juga berfungsi jika kita membuat kueri melakukan sedikit lebih banyak pekerjaan – kueri di atas dianggap sepele oleh pengoptimal, dan tanda jejak tidak' t bahkan mencoba untuk melakukan apa pun dalam kasus itu. Tapi itu akan muncul jika optimasi berbasis biaya dilakukan, bahkan tanpa bergabung; bendera jejak sama sekali tidak berpengaruh pada rencana sepele. Berikut adalah contoh paket non-sepele yang tidak melibatkan penggabungan:

DBCC TRACEON(2453);
 
DECLARE @t TABLE(id INT PRIMARY KEY, name SYSNAME NOT NULL UNIQUE);
 
INSERT @t SELECT TOP (1000) [object_id], name FROM sys.all_objects;
 
SELECT TOP (100) t.id, t.name
  FROM @t AS t ORDER BY NEWID();
 
SELECT TOP (100) t.id, t.name
  FROM @t AS t ORDER BY NEWID() OPTION (RECOMPILE);
 
DBCC TRACEOFF(2453);

Rencana ini tidak lagi sepele; pengoptimalan ditandai sebagai penuh. Sebagian besar biaya dipindahkan ke operator sortir:

Rencana grafis yang tidak terlalu sepele

Dan perkiraan berbaris untuk kedua kueri (saya akan menyimpan tips alat kali ini, tetapi saya dapat meyakinkan Anda bahwa keduanya sama):

Kisi pernyataan untuk rencana yang tidak terlalu sepele dengan dan tanpa petunjuk kompilasi ulang

Jadi sepertinya artikel KB tidak sepenuhnya akurat – saya bisa memaksakan perilaku yang diharapkan dari tanda jejak tanpa memperkenalkan gabungan. Tapi saya juga ingin mengujinya dengan bergabung.

Tes yang Lebih Baik

Mari kita ambil contoh sederhana ini, dengan dan tanpa tanda jejak:

--DBCC TRACEON(2453);
 
DECLARE @t TABLE(id INT PRIMARY KEY, name SYSNAME NOT NULL UNIQUE);
 
INSERT @t SELECT TOP (1000) [object_id], name FROM sys.all_objects;
 
SELECT t.name, c.name
  FROM @t AS t
  LEFT OUTER JOIN sys.all_columns AS c
  ON t.id = c.[object_id];
 
--DBCC TRACEOFF(2453);

Tanpa tanda jejak, pengoptimal memperkirakan bahwa satu baris akan berasal dari pemindaian indeks terhadap variabel tabel. Namun, dengan tanda jejak diaktifkan, itu membuat 1.000 baris menggedor:

Perbandingan perkiraan pemindaian indeks (tidak ada tanda jejak di sebelah kiri, jejak bendera di sebelah kanan)

Perbedaan tidak berhenti di situ. Jika kita melihat lebih dekat, kita dapat melihat berbagai keputusan berbeda yang telah dibuat oleh pengoptimal, semuanya berasal dari perkiraan yang lebih baik ini:

Perbandingan rencana (tidak ada tanda jejak di sebelah kiri, tanda jejak di sebelah kanan)

Ringkasan singkat tentang perbedaannya:

• Kueri tanpa tanda jejak telah melakukan 4.140 operasi baca, sedangkan kueri dengan perkiraan yang ditingkatkan hanya melakukan 424 (pengurangan sekitar 90%).
• Pengoptimal memperkirakan bahwa seluruh kueri akan mengembalikan 10 baris tanpa tanda pelacakan, dan 2.318 baris yang jauh lebih akurat saat menggunakan tanda pelacakan.
• Tanpa tanda jejak, pengoptimal memilih untuk melakukan penggabungan loop bersarang (yang masuk akal ketika salah satu input diperkirakan sangat kecil). Hal ini menyebabkan operator penggabungan dan kedua indeks berusaha mengeksekusi 1.000 kali, berbeda dengan pencocokan hash yang dipilih di bawah tanda pelacakan, di mana operator penggabungan dan kedua pemindaian hanya dieksekusi sekali.
• Tab Tabel I/O juga menampilkan 1.000 pemindaian (pemindaian rentang yang disamarkan sebagai pencarian indeks) dan jumlah pembacaan logis yang jauh lebih tinggi dibandingkan syscolpars (tabel sistem di belakang sys.all_columns ).
• Meskipun durasi tidak terpengaruh secara signifikan (24 milidetik vs. 18 milidetik), Anda mungkin dapat membayangkan jenis dampak yang mungkin ditimbulkan oleh perbedaan lain ini pada kueri yang lebih serius.
• Jika kita mengalihkan diagram ke perkiraan biaya, kita dapat melihat betapa berbedanya variabel tabel dapat menipu pengoptimal tanpa tanda jejak:

Membandingkan perkiraan jumlah baris (tidak ada tanda jejak di sebelah kiri, jejak bendera di sebelah kanan)

Jelas dan tidak mengejutkan bahwa pengoptimal melakukan pekerjaan yang lebih baik dalam memilih rencana yang tepat ketika memiliki pandangan yang akurat tentang kardinalitas yang terlibat. Tapi berapa biayanya?

Mengkompilasi Ulang dan Overhead

Saat kita menggunakan OPTION (RECOMPILE) dengan kumpulan di atas, tanpa tanda jejak diaktifkan, kami mendapatkan paket berikut – yang cukup mirip dengan rencana dengan bendera jejak (satu-satunya perbedaan mencolok adalah perkiraan baris adalah 2.316 bukannya 2.318):

Kueri yang sama dengan OPTION (RECOMPILE)

Jadi, ini mungkin membuat Anda percaya bahwa tanda pelacakan menyelesaikan hasil yang serupa dengan memicu kompilasi ulang untuk Anda setiap saat. Kami dapat menyelidiki ini menggunakan sesi Acara Diperpanjang yang sangat sederhana:

CREATE EVENT SESSION [CaptureRecompiles] ON SERVER 
ADD EVENT sqlserver.sql_statement_recompile
  (
    ACTION(sqlserver.sql_text)
  ) 
  ADD TARGET package0.asynchronous_file_target
  (
    SET FILENAME = N'C:\temp\CaptureRecompiles.xel'
  );
GO
ALTER EVENT SESSION [CaptureRecompiles] ON SERVER STATE = START;

Saya menjalankan kumpulan kumpulan berikut, yang mengeksekusi 20 kueri dengan (a) tidak ada opsi kompilasi ulang atau tanda pelacakan, (b) opsi kompilasi ulang, dan (c) tanda pelacakan tingkat sesi.

/* default - no trace flag, no recompile */
 
DECLARE @t TABLE(id INT PRIMARY KEY, name SYSNAME NOT NULL UNIQUE);
 
INSERT @t SELECT TOP (1000) [object_id], name FROM sys.all_objects;
 
SELECT t.name, c.name
  FROM @t AS t
  LEFT OUTER JOIN sys.all_columns AS c
  ON t.id = c.[object_id];
 
GO 20
 
/* recompile */
 
DECLARE @t TABLE(id INT PRIMARY KEY, name SYSNAME NOT NULL UNIQUE);
 
INSERT @t SELECT TOP (1000) [object_id], name FROM sys.all_objects;
 
SELECT t.name, c.name
  FROM @t AS t
  LEFT OUTER JOIN sys.all_columns AS c
  ON t.id = c.[object_id] OPTION (RECOMPILE);
 
GO 20
 
/* trace flag */
 
DBCC TRACEON(2453);  
 
DECLARE @t TABLE(id INT PRIMARY KEY, name SYSNAME NOT NULL UNIQUE);
 
INSERT @t SELECT TOP (1000) [object_id], name FROM sys.all_objects;
 
SELECT t.name, c.name
  FROM @t AS t
  LEFT OUTER JOIN sys.all_columns AS c
  ON t.id = c.[object_id];
 
DBCC TRACEOFF(2453);
 
GO 20

Kemudian saya melihat data acara:

SELECT 
  sql_text = LEFT(sql_text, 255),
  recompile_count = COUNT(*)
FROM 
(
  SELECT 
    x.x.value(N'(event/action[@name="sql_text"]/value)[1]',N'nvarchar(max)')
  FROM 
    sys.fn_xe_file_target_read_file(N'C:\temp\CaptureRecompiles*.xel',NULL,NULL,NULL) AS f
    CROSS APPLY (SELECT CONVERT(XML, f.event_data)) AS x(x)
) AS x(sql_text)
GROUP BY LEFT(sql_text, 255);

Hasilnya menunjukkan bahwa tidak ada kompilasi ulang yang terjadi di bawah kueri standar, pernyataan yang mereferensikan variabel tabel dikompilasi ulang sekali di bawah bendera jejak dan, seperti yang Anda duga, setiap saat dengan RECOMPILE pilihan:

Hasil kueri terhadap data XEvents

Selanjutnya, saya mematikan sesi Extended Events, lalu mengubah batch untuk mengukur pada skala. Pada dasarnya kode ini mengukur 1.000 iterasi untuk membuat dan mengisi variabel tabel, lalu memilih hasilnya menjadi tabel #temp (salah satu cara untuk menekan output dari banyak kumpulan hasil sekali pakai), menggunakan masing-masing dari tiga metode.

SET NOCOUNT ON;
 
/* default - no trace flag, no recompile */
 
SELECT SYSDATETIME();
GO
DECLARE @t TABLE(id INT PRIMARY KEY, name SYSNAME NOT NULL UNIQUE);
 
INSERT @t SELECT TOP (1000) [object_id], name FROM sys.all_objects;
 
SELECT t.id, c.name
  INTO #x
  FROM @t AS t
  LEFT OUTER JOIN sys.all_columns AS c
  ON t.id = c.[object_id];
 
DROP TABLE #x;
 
GO 1000
SELECT SYSDATETIME();
GO
 
 
/* recompile */
 
DECLARE @t TABLE(id INT PRIMARY KEY, name SYSNAME NOT NULL UNIQUE);
 
INSERT @t SELECT TOP (1000) [object_id], name FROM sys.all_objects;
 
SELECT t.id, c.name
  INTO #x
  FROM @t AS t
  LEFT OUTER JOIN sys.all_columns AS c
  ON t.id = c.[object_id] OPTION (RECOMPILE);
 
DROP TABLE #x;
 
GO 1000
SELECT SYSDATETIME();
GO
 
 
/* trace flag */
 
DBCC TRACEON(2453);  
 
DECLARE @t TABLE(id INT PRIMARY KEY, name SYSNAME NOT NULL UNIQUE);
 
INSERT @t SELECT TOP (1000) [object_id], name FROM sys.all_objects;
 
SELECT t.id, c.name
  INTO #x
  FROM @t AS t
  LEFT OUTER JOIN sys.all_columns AS c
  ON t.id = c.[object_id];
 
DROP TABLE #x;
 
DBCC TRACEOFF(2453);  
 
GO 1000
SELECT SYSDATETIME();
GO

Saya menjalankan batch ini 10 kali dan mengambil rata-rata; mereka adalah:

CREATE EVENT SESSION [CaptureRecompiles_v2] ON SERVER 
ADD EVENT sqlserver.sql_statement_recompile
  (
    ACTION(sqlserver.sql_text)
  ) 
  ADD TARGET package0.asynchronous_file_target
  (
    SET FILENAME = N'C:\temp\CaptureRecompiles_v2.xel'
  );
GO
ALTER EVENT SESSION [CaptureRecompiles_v2] ON SERVER STATE = START;

/* default, no trace flag or recompile */
/* recompile */
/* trace flag */
 
DECLARE @i INT = 1;
 
WHILE @i <= 6
BEGIN
  --DBCC TRACEON(2453); -- uncomment this for trace flag
 
  DECLARE @t TABLE(id INT PRIMARY KEY);
 
  INSERT @t SELECT TOP (CASE @i 
      WHEN 1 THEN 24
	  WHEN 2 THEN 1782
	  WHEN 3 THEN 1701
	  WHEN 4 THEN 12
	  WHEN 5 THEN 15
	  WHEN 6 THEN 1560 
	END) [object_id]
    FROM sys.all_objects;
 
  SELECT t.id, c.name
    FROM @t AS t
    INNER JOIN sys.all_objects AS c
    ON t.id = c.[object_id]
    --OPTION (RECOMPILE); -- uncomment this for recompile
 
  --DBCC TRACEOFF(2453); -- uncomment this for trace flag
 
  DELETE @t;
  SET @i += 1;
END

SELECT 
  sql_text = LEFT(sql_text, 255),
  recompile_count = COUNT(*)
FROM 
(
  SELECT 
    x.x.value(N'(event/action[@name="sql_text"]/value)[1]',N'nvarchar(max)')
  FROM 
    sys.fn_xe_file_target_read_file(N'C:\temp\CaptureRecompiles_v2*.xel',NULL,NULL,NULL) AS f
    CROSS APPLY (SELECT CONVERT(XML, f.event_data)) AS x(x)
) AS x(sql_text)
GROUP BY LEFT(sql_text, 255);

USE MyTestDB;
GO
 
CREATE TYPE dbo.t AS TABLE 
(
  id INT PRIMARY KEY
);