Memory-Optimized Tabloları için Sorgu İşleme Kılavuzu

Şunlar için geçerlidir:SQL ServerAzure SQL VeritabanıAzure SQL Yönetilen Örneği

In-Memory OLTP, SQL Server'da bellek için iyileştirilmiş tablolar ve yerel olarak derlenmiş saklı yordamlar sunar. Bu makalede hem bellek için iyileştirilmiş tablolar hem de yerel olarak derlenmiş saklı yordamlar için sorgu işlemeye genel bir bakış verilmektedir.

Belge, bellek optimizasyonlu tablolardaki sorguların nasıl derlenip yürütüldüğünü, şunlar dahil olmak üzere, açıklar:

• Disk tabanlı tablolar için SQL Server'da sorgu işleme işlem hattı.

• Sorgu iyileştirme; bellek için iyileştirilmiş tablolardaki istatistiklerin rolü ve hatalı sorgu planlarıyla ilgili sorunları giderme yönergeleri.

• Bellek için iyileştirilmiş tablolara erişmek için yorumlanmış Transact-SQL kullanımı.

• Bellek iyileştirmesi yapılmış tablo erişimi için sorgu optimizasyonu hakkında dikkate alınması gerekenler.

• Yerel ortamda derlenen saklı yordamların derlenmesi ve işlenmesi.

• İyileştirici tarafından maliyet tahmini için kullanılan istatistikler.

• Hatalı sorgu planlarını düzeltmenin yolları.

Örnek Sorgu

Aşağıdaki örnek, bu makalede ele alınan sorgu işleme kavramlarını göstermek için kullanılacaktır.

Müşteri ve Sipariş olarak iki tabloyu dikkate alıyoruz. Aşağıdaki Transact-SQL betiği, bu iki tablonun ve ilişkili dizinlerin tanımlarını (geleneksel) disk tabanlı biçimlerinde içerir:

CREATE TABLE dbo.[Customer] (  
  CustomerID nchar (5) NOT NULL PRIMARY KEY,  
  ContactName nvarchar (30) NOT NULL   
)  
GO  
  
CREATE TABLE dbo.[Order] (  
  OrderID int NOT NULL PRIMARY KEY,  
  CustomerID nchar (5) NOT NULL,  
  OrderDate date NOT NULL  
)  
GO  
CREATE INDEX IX_CustomerID ON dbo.[Order](CustomerID)  
GO  
CREATE INDEX IX_OrderDate ON dbo.[Order](OrderDate)  
GO  

Bu makalede gösterilen sorgu planlarını oluşturmak için, iki tablo Northwind örnek veritabanından alınan örnek verilerle dolduruldu, bu verileri Northwind ve SQL Server 2000 için Örnek Veritabanlarındanindirebilirsiniz.

Müşteri ve Sipariş tablolarını birleştiren ve siparişin kimliğini ve ilişkili müşteri bilgilerini döndüren aşağıdaki sorguyu göz önünde bulundurun:

SELECT o.OrderID, c.* FROM dbo.[Customer] c INNER JOIN dbo.[Order] o ON c.CustomerID = o.CustomerID  

SQL Server Management Studio tarafından görüntülenen tahmini yürütme planı aşağıdaki gibidir

Disk tabanlı tabloların birleşimi için sorgu planı.

Bu sorgu planı hakkında:

• Customer tablosundaki satırlar, birincil veri yapısı olan ve tam tablo verilerine sahip olan kümelenmiş dizinden alınır.

• Sipariş tablosundaki veriler CustomerID sütunundaki kümelenmemiş dizin kullanılarak alınır. Bu dizin hem birleştirme için kullanılan CustomerID sütununu hem de kullanıcıya döndürülen birincil anahtar sütununu OrderID içerir. Order tablosundan ek sütunlar döndürülmesi için Order tablosunun kümelenmiş dizininde arama yapılması gerekir.

• Mantıksal işleç İç Birleştirme, fiziksel işleç Birleştirme Bağlamasıtarafından uygulanır. Diğer fiziksel birleştirme türleri İç İçe Döngüler ve Karma Birleştirme. Birleştirme Birleştir işleci, her iki dizinin de birleştirme sütunu CustomerID'ye göre sıralanmış olmasından yararlanır.

Bu sorguda yalnızca OrderID sütununu değil, Order tablosundaki tüm sütunları döndüren küçük bir çeşitlemesi düşünün:

SELECT o.*, c.* FROM dbo.[Customer] c INNER JOIN dbo.[Order] o ON c.CustomerID = o.CustomerID  

Bu sorgu için tahmini plan:

Disk tabanlı tabloların karma birleşimi için sorgu planı.

Bu sorguda, Order tablosundaki satırlar kümelenmiş dizin kullanılarak alınır. Karma Eşleştirme fiziksel işleci artık İç Birleştirme'te kullanılmaktadır. Sipariş'teki kümelenmiş dizin, CustomerID üzerinde sıralı değildir, bu yüzden Birleştirme bir sıralama işleci gerektirir ve bu performansı etkiler. Karma Eşleştirme işlecinin (75%) göreli maliyetini, önceki örnekteki Birleştirme Bağlama işlecinin maliyetiyle (46%) karşılaştırarak not edin. Optimizatör, önceki örnekte Karma Eşleştirme işlecini de göz önünde bulundurmuş, ancak Birleştirme Birleştirme işlecinin daha iyi performans verdiği sonucuna varmıştır.

Disk-Based Tabloları için SQL Server Sorgu İşleme

Aşağıdaki diyagramda geçici sorgular için SQL Server'daki sorgu işleme akışı özetlenmiştir:

SQL Server sorgu işleme işlem hattını
SQL Server sorgu işleme işlem hattı.

Bu senaryoda:

1. Kullanıcı bir sorgu oluşturur.

2. Ayrıştırıcı ve cebirci, kullanıcı tarafından gönderilen Transact-SQL metnine göre mantıksal işleçlerle bir sorgu ağacı oluşturur.

3. İyileştirici, fiziksel işleçler içeren iyileştirilmiş bir sorgu planı oluşturur (örneğin, iç içe döngüler birleştirme). İyileştirmeden sonra plan, plan önbelleğinde depolanabilir. Plan önbelleği bu sorgu için zaten bir plan içeriyorsa bu adım atlanır.

4. Sorgu yürütme altyapısı, sorgu planının yorumunu işler.

5. Her dizin arama, dizin taraması ve tablo tarama işleci için yürütme altyapısı, Access Yöntemleri'nden ilgili dizin ve tablo yapılarından satırlar ister.

6. Access Yöntemleri, arabellek havuzundaki dizin ve veri sayfalarından satırları alır ve diskteki sayfaları gerektiğinde arabellek havuzuna yükler.

İlk örnek sorgu için, yürütme altyapısı Müşteri'deki kümelenmiş dizinde ve Access Yöntemlerinden Sipariş'teki kümelenmemiş dizinde satırlar istemektedir. Access Yöntemleri, istenen satırları almak için B ağacı dizin yapılarını gezer. Bu durumda plan tam dizin taramaları gerektirdiği için tüm satırlar çağrılır.

Not

Belgelerde genellikle dizinlere başvuruda B ağacı terimi kullanılır. Rowstore dizinlerinde Veritabanı Altyapısı bir B+ ağacı uygular. Bu, columnstore dizinleri veya bellek iyileştirmeli tablolardaki dizinler için geçerli değildir. Daha fazla bilgi için SQL Server ve Azure SQL dizin mimarisi ve tasarım kılavuzuna bakın.

Memory-Optimized Tablolara Yorumlanmış Transact-SQL Erişimi

Transact-SQL geçici toplu işlemler ve saklı yordamlar da yorumlanmış Transact-SQL olarak adlandırılır. Yorumlanan, sorgu planının sorgu planındaki her işleç için sorgu yürütme altyapısı tarafından yorumlandığı gerçeğini ifade eder. Yürütme motoru işlecini ve parametrelerini okur ve işlemi gerçekleştirir.

Yorumlayıcı Transact-SQL, hem bellek iyileştirmeli hem de disk tabanlı tablolara erişmek için kullanılabilir. Aşağıdaki şekil, yorumlanmış Transact-SQL erişimi yoluyla bellek için optimize edilmiş tablolara yönelik sorgu işlemesini göstermektedir.

yorumlanan tsql için sorgu işleme işlem hattını
Bellek için iyileştirilmiş tablolara yorumlanmış Transact-SQL erişimi için sorgu işleme hattı.

Şekilde gösterildiği gibi, sorgu işleme işlem hattı çoğunlukla değişmeden kalır:

• Ayrıştırıcı ve cebirci sorgu ağacını oluşturur.

• İyileştirici yürütme planını oluşturur.

• Sorgu yürütme altyapısı yürütme planını yorumlar.

Geleneksel sorgu işleme işlem hattıyla (şekil 2) arasındaki temel fark, bellek için iyileştirilmiş tablolara ait satırların Erişim Yöntemleri kullanılarak arabellek havuzundan alınmamasıdır. Bunun yerine, satırlar In-Memory OLTP altyapısı aracılığıyla bellek içi veri yapılarından alınır. Veri yapılarındaki farklılıklar, aşağıdaki örnekte gösterildiği gibi iyileştiricinin bazı durumlarda farklı planlar seçmesine neden olur.

Aşağıdaki Transact-SQL betiği, karma dizinleri kullanılarak Sipariş ve Müşteri tablolarının bellek için iyileştirilmiş sürümlerini içerir:

CREATE TABLE dbo.[Customer] (  
  CustomerID nchar (5) NOT NULL PRIMARY KEY NONCLUSTERED,  
  ContactName nvarchar (30) NOT NULL   
) WITH (MEMORY_OPTIMIZED=ON)  
GO  
  
CREATE TABLE dbo.[Order] (  
  OrderID int NOT NULL PRIMARY KEY NONCLUSTERED,  
  CustomerID nchar (5) NOT NULL INDEX IX_CustomerID HASH(CustomerID) WITH (BUCKET_COUNT=100000),  
  OrderDate date NOT NULL INDEX IX_OrderDate HASH(OrderDate) WITH (BUCKET_COUNT=100000)  
) WITH (MEMORY_OPTIMIZED=ON)  
GO  

Bellek için iyileştirilmiş tablolarda yürütülen sorgunun aynısını göz önünde bulundurun:

SELECT o.OrderID, c.* FROM dbo.[Customer] c INNER JOIN dbo.[Order] o ON c.CustomerID = o.CustomerID  

Tahmini plan aşağıdaki gibidir:

Bellek için iyileştirilmiş tabloların birleşimi için sorgu planı
Bellek ile iyileştirilmiş tabloların birleşimi için sorgu planı.

Disk tabanlı tablolarda aynı sorgunun planıyla aşağıdaki farkları gözlemleyin (şekil 1):

• Bu plan, Müşteri tablosu için kümelenmiş dizin taraması yerine tablo taraması içeriyor:

  • Tablonun tanımı kümelenmiş dizin içermiyor.

  • Kümelenmiş dizinler bellek için iyileştirilmiş tablolarda desteklenmez. Bunun yerine, bellek için iyileştirilmiş her tablonun en az bir kümelenmemiş dizini olmalıdır ve bellek için iyileştirilmiş tablolardaki tüm dizinler, bunları dizinde depolamak veya kümelenmiş dizine başvurmak zorunda kalmadan tablodaki tüm sütunlara verimli bir şekilde erişebilir.

• Bu plan Birleştirme Birleştirmeyerine Karma Eşleştirme içerir. Hem Sipariş hem de Müşteri tablosundaki dizinler karma dizinlerdir ve bu nedenle sıralanmaz. Birleştirme Bağlantısı, performansı düşüren sıralama operatörleri gerektirir.

Yerel Olarak Derlenmiş Saklı Yordamlar

Yerel olarak derlenmiş saklı yordamlar, sorgu yürütme altyapısı tarafından yorumlanmak yerine makine koduna derlenmiş Transact-SQL saklı yordamlardır. Aşağıdaki betik, örnek sorguyu (Örnek Sorgu bölümünden) çalıştıran yerel olarak derlenmiş bir saklı yordam oluşturur.

CREATE PROCEDURE usp_SampleJoin  
WITH NATIVE_COMPILATION, SCHEMABINDING, EXECUTE AS OWNER  
AS BEGIN ATOMIC WITH   
(  TRANSACTION ISOLATION LEVEL = SNAPSHOT,  
  LANGUAGE = 'english')  
  
  SELECT o.OrderID, c.CustomerID, c.ContactName   
FROM dbo.[Order] o INNER JOIN dbo.[Customer] c   
  ON c.CustomerID = o.CustomerID  
  
END  

Yerel olarak derlenmiş saklı yordamlar oluşturma zamanında derlenirken, yorumlanan saklı yordamlar ilk yürütme zamanında derlenir. (Derlemenin bir bölümü, özellikle ayrıştırma ve cebirleştirme oluşturma aşamasında gerçekleşir. Ancak, yorumlanan depolanmış prosedürler için sorgu planlarının optimize edilmesi ilk çalıştırmada gerçekleşir.) Yeniden derleme mantığı benzerdir. Yerel olarak derlenmiş saklı yordamlar, sunucu yeniden başlatılırsa yordamın ilk yürütülmesinde yeniden derlenir. Plan artık plan önbelleğinde değilse yorumlanmış saklı yordamlar yeniden derlenir. Aşağıdaki tabloda hem yerel olarak derlenmiş hem de yorumlanmış saklı yordamlar için derleme ve yeniden derleme durumları özetlenmiştir:

Derleme türü	Yerel olarak derlenmiş	Yorumlanır
İlk derleme	Oluşturma anında.	İlk yürütmede.
Otomatik yeniden derleme	Bir veritabanı veya sunucu yeniden başlatıldıktan sonra yordamın ilk kez yürütülmesi sırasında.	Sunucu yeniden başlatıldığında. Ya da genellikle şema veya istatistik değişikliklerine ya da bellek baskısına bağlı olarak plan önbelleğinden çıkarma.
El ile yeniden derleme	sp_recompilekullanın.	sp_recompilekullanın. Planı önbellekten el ile çıkarabilirsiniz, örneğin DBCC FREEPROCCACHE aracılığıyla. Ayrıca RECOMPILE ile saklı yordamı oluşturabilirsiniz ve saklı yordam her yürütmede yeniden derlenir.

Derleme ve Sorgu İşleme

Aşağıdaki diyagramda yerel olarak derlenmiş saklı yordamlar için derleme işlemi gösterilmektedir:

Doğal olarak derlenen saklı yordamlar.
Saklı yordamların yerel derlemesi.

İşlem şu şekilde açıklanmıştır:

1. Kullanıcı SQL Server'a bir CREATE PROCEDURE deyimi gönderir.

2. Ayrıştırıcı ve cebirci, yordamın işleme akışını ve saklı yordamdaki Transact-SQL sorguları için sorgu ağaçlarını oluşturur.

3. İyileştirici saklı yordamdaki tüm sorgular için iyileştirilmiş sorgu yürütme planları oluşturur.

4. In-Memory OLTP derleyicisi, tümleşik iyileştirilmiş sorgu planlarıyla işleme akışını alır ve saklı yordamı yürütmek için makine kodunu içeren bir DLL oluşturur.

5. Oluşturulan DLL belleğe yüklenir.

Yerel olarak derlenmiş saklı yordamın çağrılması, DLL'deki bir fonksiyonun çağrılmasına dönüştürülür.

Yerel olarak derlenmiş saklı prosedürlerin yürütülmesi.

Doğrudan derlenen bir saklı yordamın çağrılması aşağıdaki gibi açıklanmıştır:

1. Kullanıcı bir EXECusp_myproc deyimini oluşturur.

2. Ayrıştırıcı, ad ve saklı yordam parametrelerini ayıklar.

   Deyimi, örneğin sp_prep_execkullanılarak hazırlanmışsa, ayrıştırıcının yürütme zamanında yordam adını ve parametrelerini ayıklaması gerekmez.

3. In-Memory OLTP çalışma zamanı, saklı yordam için DLL giriş noktasını bulur.

4. DLL'deki makine kodu yürütülür ve sonuçları istemciye döndürülür.

Parametre algılama

Yorumlanan Transact-SQL saklı yordamlar, oluşturma zamanında derlenen yerel olarak derlenmiş saklı yordamların aksine ilk yürütmede derlenir. Çağrı sırasında derlenen saklı yordamlar yorumlandığında, bu çağrı için sağlanan parametrelerin değerleri, yürütme planı oluşturulurken iyileştirici tarafından kullanılır. Derleme sırasında parametrelerin bu kullanımına parametre algılama denir.

Parametre algılama, yerel olarak derlenmiş saklı yordamları derlemek için kullanılmaz. Saklı prosedüre yönelik tüm parametrelerin BİLİNMEYEN değerlere sahip olduğu kabul edilir. Yorumlanmış saklı yordamlar gibi, yerel olarak derlenmiş saklı yordamlar da OPTIMIZE FOR ipucunu destekler. Daha fazla bilgi için bkz. Sorgu İpuçları (Transact-SQL).

Yerel Olarak Derlenmiş Saklı Yordamlar için Sorgu Yürütme Planı Alma

Yerel olarak derlenmiş bir saklı yordam için sorgu yürütme planı, Management Studio'daki Tahmini Yürütme Planı kullanılarak veya Transact-SQL'deki SHOWPLAN_XML seçeneği kullanılarak alınabilir. Mesela:

SET SHOWPLAN_XML ON  
GO  
EXEC dbo.usp_myproc  
GO  
SET SHOWPLAN_XML OFF  
GO  

Sorgu iyileştiricisi tarafından oluşturulan yürütme planı, düğümlerde sorgu işleçleri ve ağacın yaprakları olan bir ağaçtan oluşur. Ağacın yapısı, işleçler arasındaki etkileşimi (bir işleçten diğerine satır akışı) belirler. SQL Server Management Studio'nun grafik görünümünde akış sağdan soladır. Örneğin, şekil 1'deki sorgu planı, birleştirme birleştirme işlecine satır sağlayan iki dizin tarama işleci içerir. Birleştirme işleci, satırları bir seçim işlecine sağlar. Select işleci son olarak satırları istemciye döndürür.

Yerel Olarak Derlenmiş Saklı Yordamlarda Sorgu İşleçleri

Aşağıdaki tabloda, yerel olarak derlenmiş saklı yordamlarda desteklenen sorgu işleçleri özetlenmektedir:

Operatör	Örnek sorgu	Notlar
SEÇ	SELECT OrderID FROM dbo.[Order]
SOKMAK	INSERT dbo.Customer VALUES ('abc', 'def')
GÜNCELLEŞTİRMEK	UPDATE dbo.Customer SET ContactName='ghi' WHERE CustomerID='abc'
SİLMEK	DELETE dbo.Customer WHERE CustomerID='abc'
İşlem Skaler	SELECT OrderID+1 FROM dbo.[Order]	Bu işleç hem iç işlevler hem de tür dönüştürmeleri için kullanılır. Tüm işlevler ve tür dönüştürmeleri yerel olarak derlenmiş saklı yordamlar içinde desteklenmez.
İç İçe Döngülere Katılma	SELECT o.OrderID, c.CustomerID FROM dbo.[Order] o INNER JOIN dbo.[Customer] c	İç İçe Döngüleme, yerel olarak derlenmiş depolanan yordamlar içinde desteklenen tek birleştirme işlecidir. Birleştirme içeren tüm planlar, yorumlanan Transact-SQL sorgusu için yürütülen aynı sorgunun planı bir karma veya birleştirme içerse bile, İç İçe Döngüler işlecini kullanacaktır.
Sırala	SELECT ContactName FROM dbo.Customer ORDER BY ContactName
Yukarı	SELECT TOP 10 ContactName FROM dbo.Customer
En üstte sırala	SELECT TOP 10 ContactName FROM dbo.Customer ORDER BY ContactName	TOP ifadesi (döndürülecek satır sayısı) 8.000 satırı aşamaz. Sorguda birleştirme ve toplama işleçleri de varsa daha az. Birleştirmeler ve toplamalar genellikle temel tabloların satır sayısıyla karşılaştırıldığında sıralanacak satır sayısını azaltır.
Akış Toplama	SELECT count(CustomerID) FROM dbo.Customer	Karma Eşleştirme işlecinin toplama için desteklenmediğini unutmayın. Bu nedenle, yerel olarak derlenmiş saklı yordamlardaki tüm toplama işlemleri, yorumlanan Transact-SQL planındaki aynı sorgu için "Hash Match" işlecini kullansa bile, "Stream Aggregate" işlecini kullanır.

Sütun İstatistikleri ve Birleştirmeleri

SQL Server, dizin taraması ve dizin aramaları gibi belirli işlemlerin maliyetini tahmin etmeye yardımcı olmak için dizin anahtarı sütunlarındaki değerlerle ilgili istatistikleri tutar. ( Açıkça oluşturursanız veya sorgu iyileştiricisi bunları bir koşula sahip bir sorguya yanıt olarak oluşturursa, SQL Server dizin olmayan anahtar sütunlarıyla ilgili istatistikler de oluşturur.) Maliyet tahminindeki ana ölçüm, tek bir işleç tarafından işlenen satır sayısıdır. Disk tabanlı tablolarda, belirli bir işleç tarafından erişilen sayfa sayısının maliyet tahmini açısından önemli olduğunu unutmayın. Ancak, sayfa sayısı bellek için iyileştirilmiş tablolar için önemli olmadığından (her zaman sıfırdır), bu tartışma satır sayısına odaklanır. Tahmin, plandaki dizin arama ve tarama işleçleriyle başlar ve daha sonra birleştirme işleci gibi diğer işleçleri içerecek şekilde genişletilir. Birleştirme işleci tarafından işlenecek tahmini satır sayısı, temel alınan dizin, arama ve tarama işleçlerinin tahminini temel alır. Bellek için iyileştirilmiş tablolara yönelik yorumlanmış Transact-SQL erişiminde, plandaki operatörlerin tahmini ve gerçek satır sayıları arasındaki farkı görmek için gerçek yürütme planını inceleyebilirsiniz.

Şekil 1'deki örnek için

• Müşterideki kümelenmiş dizin taraması tahmini 91; gerçek 91.
• CustomerID'de kümelenmemiş dizin taraması tahmini 830; gerçek 830.
• Birleştirme operatörü tahmini 815; gerçek 830.

Dizin taramaları için tahminler doğrudur. SQL Server, disk tabanlı tablolar için satır sayısını korur. Tam tablo ve dizin taramaları için tahminler her zaman doğrudur. Birleştirme tahmini de oldukça doğrudur.

Bu tahminler değişirse, farklı plan alternatifleri için maliyetle ilgili dikkat edilmesi gerekenler de değişir. Örneğin, birleştirmedeki taraflardan birinin tahmini satır sayısı 1 veya sadece birkaç satırsa, iç içe döngü birleştirmelerin kullanılması daha maliyetsizdir. Aşağıdaki sorguyu göz önünde bulundurun:

SELECT o.OrderID, c.* FROM dbo.[Customer] c INNER JOIN dbo.[Order] o ON c.CustomerID = o.CustomerID  

Customer tablosunda bir satır dışında tüm satırlar silindikten sonra aşağıdaki sorgu planı oluşturulur:

Sütun istatistikleri ve birleştirmeler

Bu sorgu planıyla ilgili olarak:

• Karma Eşleştirme, İç İçe Döngüler fiziksel birleştirme işleciyle değiştirildi.
• IX_CustomerID'da tam dizin taraması bir dizin aramasıyla değiştirildi. Bu, tam dizin taraması için gereken 830 satır yerine 5 satırın taranmasıyla sonuçlandı.

Ayrıca Bkz.

Memory-Optimized Tablolar