Aracılığıyla paylaş

Columnstore dizinleri - sorgu performansı

Şunlar için geçerlidir:SQL ServerAzure SQL DatabaseAzure SQL Managed InstanceAzure Synapse AnalyticsAnalitik Platform Sistemi (PDW)Microsoft Fabric'te SQL veritabanı

Bu makale, columnstore dizinleriyle hızlı sorgu performansı elde etmek için öneriler içerir.

Columnstore dizinleri analiz ve veri ambarı iş yüklerinde 100 kata kadar daha iyi performans elde edebilir ve geleneksel rowstore dizinlerine göre 10 kata kadar daha iyi veri sıkıştırması elde edebilir. Bu öneriler, sorgularınızın columnstore dizinlerinin sağlamak üzere tasarlandığı hızlı sorgu performansını elde etmelerine yardımcı olur.

Sorgu performansını iyileştirmeye yönelik öneriler

Aşağıda, sağlamak üzere tasarlanmış yüksek performanslı columnstore dizinlerine ulaşmak için bazı öneriler bulabilirsiniz.

1. Tam tablo taramasından daha fazla satır grubunu ortadan kaldırmak için verileri düzenleyin

  • Sipariş ekle'yi dikkatle seçin. Geleneksel veri ambarında sık karşılaşılan durumlarda, veriler gerçekten zaman sırasına eklenir ve analiz zaman boyutunda yapılır. Örneğin, satışları üç aylık döneme göre analiz etme. Bu tür bir iş yükü için satır grubu eleme işlemi otomatik olarak gerçekleşir. SQL Server 2016'da (13.x), sorgu işleme kapsamında atlanan satır gruplarının sayısını bulabilirsiniz.

  • Kümelenmiş satır deposu dizini kullanın. Eğer ortak sorgu ön koşulu, ekleme sırasıyla ilişkili olmayan bir sütunda (örneğin, C1) ise, C1sütununda bir satır deposu kümelenmiş indeks oluşturun. Ardından, satır deposu kümelenmiş dizinini bırakın ve kümelenmiş bir sütun deposu dizini oluşturun. kümelenmiş columnstore dizinini açıkça MAXDOP = 1kullanarak oluşturursanız, sonuçta elde edilen kümelenmiş columnstore dizini C1sütununda mükemmel bir şekilde sıralanır. MAXDOP = 8belirtirseniz, sekiz satır grubu arasında değerlerin çakışması görürsünüz. Kümelenmemiş columnstore dizini (NCCI) için, tabloda bir satır deposu üzerinde kümelenmiş bir dizin varsa, satırlar zaten kümelenmiş dizin anahtarına göre sıralanmıştır. Bu durumda, kümelenmemiş columnstore dizini de otomatik olarak sıralanır. Columnstore dizini doğal olarak satırların sırasını korumaz. Yeni satırlar eklendikçe veya eski satırlar güncelleştirildikçe analiz sorgusu performansı bozulabileceğinden işlemi tekrarlamanız gerekebilir.

  • Tablo bölümlemesini uygula. Columnstore dizinini bölümleyebilir, ardından bölüm eleme özelliğini kullanarak taranacak satır grubu sayısını azaltabilirsiniz. Örneğin, olgu tablosu müşteriler tarafından yapılan satın almaları depolar. Yaygın bir sorgulama düzeni, customertemel alarak çeyrek dönem satın alımlarını bulmaktır. Bu durumda, sipariş ekleme sütununu customer sütunda bölümleme ile birleştirin. Her bölüm, her customer için, eklenme sırasında sıralanan satırları içerir. Ayrıca, columnstore'dan eski verileri kaldırmanız gerekiyorsa tablo bölümleme kullanmayı da göz önünde bulundurun. Bölümler arasında geçiş yapmak ve gerekli olmayan bölümlerin kesilmesi, parçalanma oluşturmadan verileri silmek için verimli bir stratejidir.

  • büyük miktarda veriyi silmekten kaçının. Bir satır grubundan sıkıştırılmış satırları kaldırmak zaman uyumlu bir işlem değildir. Bir satır grubunun sıkıştırmasını açmak, satırları silmek ve ardından tekrar sıkıştırmak pahalı olabilir. Bu nedenle, sıkıştırılmış satır gruplarından veri sildiğinizde, bu satır grupları daha az satır döndürse bile taranır. Birkaç satır grubu için silinen satır sayısı daha az satır grubuna birleştirilecek kadar büyükse, columnstore'nun yeniden düzenlenmesi dizinin kalitesini artırır ve sorgu performansı artar. Veri silme işleminiz genellikle tüm satır gruplarını boşaltıyorsa tablo bölümleme kullanmayı göz önünde bulundurun. Artık gerekli olmayan bölümleri değiştirin ve satırları silmek yerine bu bölümleri kırpın.

    Note

    SQL Server 2019 (15.x) ile başlayarak, bir arka planda çalışan birleştirme görevi, tuple-mover'a yardımcı oluyor. Bu görev, iç eşik tarafından belirlendiği gibi bir süredir var olan daha küçük "OPEN" delta satır gruplarını otomatik olarak sıkıştırır veya çok sayıda satırın silindiği "COMPRESSED" satır gruplarını birleştirir. Bu, columnstore dizin kalitesini zaman içinde artırır. Columnstore dizininden büyük miktarda veriyi silmek gerekiyorsa, bu işlemi zaman içinde daha küçük silme toplu işlemlerine bölmeyi göz önünde bulundurun. Toplu işlem, arka plan birleştirme görevinin daha küçük satır gruplarını birleştirme görevini işlemesini sağlar ve dizin kalitesini artırır. Ardından, veri silme işleminden sonra dizin yeniden düzenleme bakım pencerelerini zamanlamanız gerekmez. Columnstore terimleri ve kavramları hakkında daha fazla bilgi için bkz. Columnstore dizinleri: genel bakış.

2. Paralel olarak columnstore dizinleri oluşturmak için yeterli belleği planlayın

Bellek kısıtlanmadığı sürece columnstore dizini oluşturmak varsayılan olarak paralel bir işlemdir. Dizini paralel olarak oluşturmak, dizini seri olarak oluşturmaktan daha fazla bellek gerektirir. Fazla bellek olduğunda, sütun deposu dizini oluşturmak, aynı sütunlarda B ağacı oluşturmanın 1,5 katı kadar sürer.

Columnstore dizini oluşturmak için gereken bellek, sütun sayısına, dize sütunlarının sayısına, paralellik derecesine (DOP) ve verilerin özelliklerine bağlıdır. Örneğin, tablonuzda bir milyondan az satır varsa, Veritabanı Altyapısı columnstore dizinini oluşturmak için yalnızca bir iş parçacığı kullanır.

Tablonuzda bir milyondan fazla satır varsa ancak Veritabanı Altyapısı MAXDOP kullanarak dizin oluşturmak için yeterli bellek izni alamıyorsa, Veritabanı Altyapısı gerektiğinde otomatik olarak azalır MAXDOP . Bazı durumlarda, kullanılabilir bellek tahsisi dahilinde kısıtlı bellek koşullarında dizin oluşturmak için DOP'un bire düşürülmesi gerekir.

SQL Server 2016 (13.x) olduğundan, sorgu her zaman toplu iş modunda çalışır. Önceki sürümlerde toplu yürütme yalnızca DOP birden büyük olduğunda kullanılır.

Columnstore performansına açıklama

Columnstore dizinleri, yüksek hızlı bellek içi toplu iş modu işlemesini G/Ç gereksinimlerini büyük ölçüde azaltan tekniklerle birleştirerek yüksek sorgu performansı elde eder. Analiz sorguları çok sayıda satırı taradığından genellikle G/Ç'ye bağlıdır ve bu nedenle sorgu yürütme sırasında G/Ç'yi azaltmak columnstore dizinlerinin tasarımı açısından kritik önem taşır. Veriler belleğe okunduktan sonra bellek içi işlemlerin sayısını azaltmak kritik önem taşır.

Columnstore dizinleri G/Ç'yi azaltır ve yüksek veri sıkıştırma, sütun deposu eleme, satır grubu kaldırma ve toplu işlem aracılığıyla bellek içi işlemleri iyileştirir.

Veri sıkıştırma

Columnstore dizinleri, rowstore dizinlerinden 10 kata kadar daha fazla veri sıkıştırması elde eder. Bu, analiz sorgularını yürütmek için gereken G/Ç'yi büyük ölçüde azaltır ve bu nedenle sorgu performansını artırır.

  • Columnstore dizinleri diskten sıkıştırılmış verileri okur ve bu da bellekte daha az bayt verinin okunmasını gerektirir.

  • Columnstore dizinleri verileri sıkıştırılmış biçimde bellekte depolar ve aynı verileri belleğe okumaktan kaçınarak G/Ç'yi azaltır. Örneğin, 10 kez sıkıştırmayla columnstore dizinleri verileri sıkıştırılmamış biçimde depolamaya kıyasla 10 kat daha fazla veriyi bellekte tutabilir. Bellekte daha fazla veri olduğunda, columnstore dizininin diskten gereksiz okumalara neden olmadan bellekte ihtiyaç duyduğu verileri bulması daha olasıdır.

  • Columnstore dizinleri verileri satır yerine sütunlara göre sıkıştırarak yüksek sıkıştırma oranları elde eder ve diskte depolanan verilerin boyutunu azaltır. Her sütun bağımsız olarak sıkıştırılır ve depolanır. Bir sütundaki veriler her zaman aynı veri türüne sahiptir ve benzer değerlere sahip olma eğilimindedir. Columnstore veri sıkıştırma teknikleri, değerler benzer olduğunda daha yüksek sıkıştırma oranları elde etmek için harikadır.

Örneğin, olgu tablosu müşteri adreslerini depolar ve country-regionsütununa sahiptir. Olası değerlerin toplam sayısı 200'den azdır. Bu değerlerden bazıları birçok kez yinelenir. Olgu tablosunda 100 milyon satır varsa, country-region sütunu kolayca sıkıştırılır ve çok az depolama gerektirir. Satır bazında sıkıştırma, sütun değerlerinin benzerliğinden bu şekilde yararlanamaz ve country-region sütunundaki değerleri sıkıştırmak için daha fazla bayt kullanması gerekir.

Sütun Çıkarma

Columnstore dizinleri, sorgu tarafından referans edilmeyen sütunlarda okumayı atlar. Sütun eleme işlemi, sorgu yürütme için G/Ç'yi daha da azaltır ve bu sorgu performansını artırır.

  • Veriler sütuna göre düzenlendiğinden ve sıkıştırıldığından sütun eleme mümkündür. Buna karşılık, veriler satır satır depolandığında, her satırdaki sütun değerleri fiziksel olarak birlikte depolanır ve kolayca ayrılamaz. Ek veriler gereksiz yere belleğe okunduğu için Sorgu İşlemcisi'nin belirli sütun değerlerini almak için bir satırın tamamında okuması ve G/Ç'yi artırması gerekir.

Örneğin, bir tabloda 50 sütun varsa ve sorgu bu sütunlardan yalnızca beşini kullanıyorsa, columnstore dizini diskten yalnızca beş sütunu getirir. Diğer 45 sütunda okumayı atlayarak ve tüm sütunların benzer boyutta olduğu varsayılarak, G/Ç'yi 90%daha azaltır. Aynı veriler bir satır deposunda depolanıyorsa, sorgu işlemcisinin kalan 45 sütunu okuması gerekir.

Satır grubu eleme işlemi

Tam tablo taramaları için verilerin büyük bir kısmı genellikle sorgu koşulu ölçütleriyle eşleşmez. Columnstore dizini, meta verileri kullanarak sorgu sonucu için gerekli verileri içermeyen satır gruplarında gerçek G/Ç olmadan okumayı atlayabilir. Satır grubu eleme olarak adlandırılan bu özellik, tam tablo taramalarında G/Ç'yi azaltır ve bu nedenle sorgu performansını artırır.

Bir columnstore dizininin ne zaman tam tablo taraması yapması gerekir?

SQL Server 2016'dan (13.x) başlayarak, kümelenmiş bir columnstore dizininde bir veya daha fazla düzenli kümelenmemiş satır deposu veya B ağacı dizinleri oluşturabilirsiniz. Kümelenmemiş B ağacı dizinleri, eşitlik koşuluna veya küçük bir değer aralığına sahip bir koşula sahip bir sorguyu hızlandırabilir. Daha karmaşık koşullarda sorgu iyileştirici tam tablo taraması seçebilir. Satır gruplarını atlama özelliği olmadan, özellikle büyük tablolar için tam tablo taraması zaman alabilir.

Tam tablo taraması için bir analiz sorgusu satır grubu elemesinden ne zaman yararlanır?

Örneğin bir perakende işletme, kümelenmiş columnstore dizini içeren bir olgu tablosu kullanarak satış verilerini modeller. Her yeni satış, bir ürünün satıldığı tarih de dahil olmak üzere işlemin çeşitli özniteliklerini depolar. İlginç bir şekilde, columnstore dizinleri sıralı düzeni garanti etmese de, bu tablodaki satırlar tarih sıralı düzende yüklenir. Zaman içinde bu tablo büyür. Perakende işletmesi son 10 yılın satış verilerini tutabilir ancak analiz sorgusunun yalnızca son çeyrek için bir toplama hesaplaması gerekebilir. Columnstore dizinleri, yalnızca tarih sütununun meta verilerine bakarak önceki 39 çeyreğin verilerine erişimi ortadan kaldırabilir. Bu, belleğe okunan ve işlenen veri miktarında 97% azalmadır.

tam tablo taramasında hangi satır grupları atlanır ?

Hangi satır gruplarının ortadan kaldırileceğini belirlemek için columnstore dizini meta verileri kullanarak her satır grubu için her sütun kesiminin en düşük ve en yüksek değerlerini depolar. Sütun segment aralıklarından hiçbiri sorgu sorgusu ölçütlerini karşılamadığında, satır grubunun tamamı gerçek giriş/çıkış işlemi yapılmadan atlanır. Bu işe yarar çünkü veriler genellikle sıralı bir düzende yüklenir. Satır sıralama garanti olmasa da, benzer veri değerleri genellikle aynı satır grubu veya komşu bir satır grubu içinde bulunur.

Satır grupları hakkında daha fazla bilgi için bkz. Columnstore dizin tasarımı yönergeleri.

Toplu modda yürütme

Batch modu yürütme, verimliliği artırmak için grupların içindeki satırları (genellikle bir kerede 900'e kadar) işler. Örneğin, sorgu SELECT SUM(Sales) FROM SalesDataSalesData tablosundaki toplam satışları hesaplar. Toplu iş modunda sorgu altyapısı verileri 900 satırlık gruplar halinde işler. Bu yaklaşım, meta veri erişim maliyetini ve diğer ek yük türlerini her satır için ek yük oluşturmak yerine toplu iş içindeki tüm satırlara yayarak azaltır. Ayrıca, toplu iş modu mümkün olduğunda sıkıştırılmış verilerle çalışır ve satır modunda kullanılan bazı exchange işleçlerini kaldırarak analiz sorgularını önemli ölçüde hızlandırır.

Tüm sorgu yürütme işleçleri toplu iş modunda yürütülemez. Örneğin, ekleme, silme veya güncelleştirme gibi veri işleme dili (DML) işlemleri bir kerede bir satır yürütülür. Tarama, Katılma, Toplama, Sıralama gibi toplu iş modu işleci sorgu performansını iyileştirebilir. Columnstore dizini SQL Server 2012'de (11.x) sunulduğundan, toplu iş modunda yürütülebilecek işleçleri genişletmek için sürekli bir çaba vardır. Aşağıdaki tabloda, ürün sürümüne göre toplu modda çalışan işleçler gösterilmektedir.

Toplu Mod Operatörleri Kullanıldığında SQL Server 2012 (11.x) SQL Server 2014 (12.x) SQL Server 2016 (13.x) ve SQL Veritabanı1 Comments
DML işlemleri (ekleme, silme, güncelleştirme, birleştirme) no no no DML ile toplu iş modunun kullanılmasından elde edilen performans kazançları önemli değildir.
columnstore indeks taraması SCAN Mevcut değil yes yes columnstore dizinleri için kestirimi SCAN düğümüne iletebiliriz.
sütun deposu indeks taraması (kümelenmemiş) SCAN yes yes yes yes
dizinde arama Mevcut değil Mevcut değil no Satır modunda kümelenmemiş bir B ağacı dizini aracılığıyla bir arama işlemi gerçekleştiriyoruz.
hesapla skaler Skaler değer olarak değerlendirilen ifade. yes yes yes Tüm toplu iş modu işleçleri gibi, veri türüyle ilgili bazı kısıtlamalar vardır.
concatenation UNION ve UNION ALL no yes yes
filter Önekleri uygulama yes yes yes
hash eşleştirmesi Karma tabanlı toplama işlevleri, dış karma birleştirme, sağ karma birleştirme, sol karma birleştirme, sağ iç birleşim, sol iç birleşim yes yes yes Toplama kısıtlamaları: metin için min/max yok. Kullanılabilir toplama işlevleri toplam/sayım/ortalama/min ve max'tir.
Birleştirme kısıtlamaları: Tamsayı olmayan türlerde eşleşmeyen tür birleştirmesi yok.
birleşik birleştirme no no no
çok iş parçacıklı sorgular yes yes yes
iç içe döngüler no no no
MAXDOP 1 altında çalışan tek iş parçacıklı sorgular no no yes
seri sorgu planına sahip tek iş parçacıklı sorgular no no yes
sort SCAN ile columnstore dizini kullanarak "order by" ifadesi. no no yes
en üstte sırala no no yes
pencere agregaları Mevcut değil Mevcut değil yes SQL Server 2016'da (13.x) yeni işleç.

1 SQL Server 2016 (13.x), SQL Veritabanı Premium katmanları, Standart katmanlar - S3 ve üzeri ile tüm sanal çekirdek katmanları ve Analiz Platformu Sistemi (PDW) için geçerlidir

Daha fazla bilgi için bkz. Sorgu İşleme Mimarisi Kılavuzu.

Toplu azaltma iletimi

SCANN düğümünden uygun satırları almak ve değerleri Batch Modunda toplamak için toplama hesaplaması için normal bir yürütme yolu. Bu, SQL Server 2016 (13.x) ile başlayarak iyi bir performans sunsa da, toplama işlemi SCAN düğümüne gönderilebilir. Toplama itelemesi, aşağıdaki koşulların karşılanması durumunda, Toplu İşlem Modu yürütmesinin üzerinde, toplam hesaplamaların performansını katlarca artırır.

  • Toplamlar MIN, MAX, SUM, COUNT ve COUNT(*).
  • Toplama işleci, GROUP BYile SCAN düğümünün veya SCAN düğümünün üzerinde olmalıdır.
  • Bu toplama ayrı bir toplama değildir.
  • Toplama sütunu bir dize sütunu değildir.
  • Toplama sütunu sanal sütun değildir.
  • Giriş ve çıkış veri türü aşağıdakilerden biri olmalı ve 64 bit içine sığmalıdır:
    • tinyint, int, bigint, smallint, bit
    • smallmoney, para, ondalık ve sayısal ile duyarlık <= 18
    • smalldate, date, datetime, datetime2, time

Örneğin, aşağıdaki sorguların her ikisinde de toplu gönderim yapılır:

SELECT  productkey, SUM(TotalProductCost)
FROM FactResellerSalesXL_CCI
GROUP BY productkey;
    
SELECT  SUM(TotalProductCost)
FROM FactResellerSalesXL_CCI;

Dize önermesi aşağıya itme

Bir veri ambarı şeması tasarlarken, önerilen şema modellemesi bir veya daha fazla olgu tablosu ve birçok boyut tablosu içeren yıldız şeması veya kar tanesi şeması kullanmaktır.

Tip

olgu tablosu iş ölçümlerini veya hareketlerini ve boyut tablosunu depolar olguların analiz edilmesi gereken boyutları depolar. Boyutsal modelleme hakkında daha fazla bilgi için bkz. Microsoft Fabric 'daBoyutlu modelleme.

Örneğin, bir olgu belirli bir bölgedeki belirli bir ürünün satışını temsil eden bir kayıt, boyut ise bir dizi bölgeyi, ürünü vb. temsil eden bir kayıt olabilir. Olgu ve boyut tabloları birincil/yabancı anahtar ilişkisiyle bağlanır. En yaygın kullanılan analiz sorguları olgu tablosuyla bir veya daha fazla boyut tablosunu birleştirir.

Productsbir boyut tablosu düşünelim. Tipik bir birincil anahtar ProductCodegenellikle dize olarak temsil edilir. Sorguların performansı için, olgu tablosundan boyut tablosundaki satıra başvurmak amacıyla genellikle tamsayı sütunu olarak kullanılan bir vekil anahtar oluşturmak en iyi uygulamadır.

columnstore dizini, sayısal veya tamsayı tabanlı anahtarları verimli bir şekilde içeren birleşimler ve koşullarla analiz sorguları çalıştırır. SQL Server 2016 (13.x), dize tabanlı sütunlara sahip analiz sorgularının performansını, dize sütunu içeren koşulları SCAN düğümüne iterek önemli ölçüde artırdı.

Dize koşulu pushdown, sorgu performansını iyileştirmek için sütunlar için oluşturulan birincil/ikincil sözlüklerden faydalanır. Örneğin, bir satır grubu içinde 100 ayrı dize değerinden oluşan bir dize sütun kesimi düşünün. Her ayrı dize değerine bir milyon satır varsayılarak ortalama 10.000 kez başvurulur. Dize önermesi indirgeme ile sorgu yürütme, önermeyi sözlükteki değerlere göre hesaplar. Koşul ifadesi uygunsa, sözlük değerine başvuran tüm satırlar otomatik olarak uygun kabul edilir. Bu, performansı iki yolla geliştirir:

  • Yalnızca uygun satır döndürülür ve tarama düğümünden dışarı akışı gereken satır sayısı azalır.
  • Dize karşılaştırmalarının sayısı azalır. Bu örnekte, 1 milyon karşılaştırmaya karşı yalnızca 100 string karşılaştırması gereklidir. Bazı sınırlamalar vardır:
    • Delta satır grupları için dize öncülü gönderimi yok. Delta satır gruplarındaki sütunlar için sözlük yoktur.
    • Sözlük 64 KB girişleri aşıyorsa dize önermesi optimizasyonu yapılmaz.
    • Null değerleri değerlendiren ifade desteklenmez.

Segment eleme işlemi

Veri türü seçimleri, columnstore dizinindeki sorgular için sorgu performansı tabanlı ortak filtre koşullarını önemli ölçüde etkileyebilir.

Columnstore verilerinde satır grupları sütun kesimlerinden oluşur. Bölümleri okumadan hızlı bir şekilde ortadan kaldırmaya olanak sağlamak için her segmente sahip meta veriler vardır. Bu segment eleme işlemi, sayısal, tarih ve saat veri türleri ve iki veya daha düşük ölçekli datetimeoffset veri türü için geçerlidir. SQL Server 2022'den (16.x) itibaren, segment eleme yetenekleri dize, ikili, guid veri türlerine ve ölçeği ikiden büyük olan datetimeoffset veri türüne genişletilir.

SQL Server 2022 (16.x) ve sonrası gibi dize min/maks aralık eleme desteğine sahip bir SQL Server sürümüne yükselttikten sonra, sütun deposu dizini ALTER INDEX REBUILD veya CREATE INDEX WITH (DROP_EXISTING = ON)kullanılarak yeniden oluşturulana kadar bu özellikten yararlanamaz.

Segment eleme, (maksimum) veri türü uzunlukları gibi LOB veri türleri için geçerli değildir.

Şu anda yalnızca SQL Server 2022 (16.x) ve sonrası, LIKE koşul ön ekine sahip kümelenmiş columnstore satır grubu elemesini destekler, örneğin column LIKE 'string%'. Segment eleme, LIKE'ın ön ek kullanılmayan örnekleri için desteklenmez, örneğin column LIKE '%string'.

Sıralı sütun deposu dizinleri özellikle dize sütunları için segment eleme avantajından da yararlanmaktadır. Sıralı columnstore dizinlerinde, sıralandığı için dizin anahtarındaki ilk sütunda segment eleme en etkili olur. Tablodaki diğer sütunlarda segment eleme nedeniyle performans kazançları, daha az öngörülebilir. Sıralı columnstore dizinleri hakkında daha fazla bilgi için Büyük veri ambarı tabloları için sıralı columnstore dizini kullanmabölümüne bakın. Sıralı columnstore dizini kullanılabilirliği için bkz. Sıralı columnstore dizini kullanılabilirliği.

SORGUSU BAĞLANTI SEÇENEĞİNİ KULLANARAKSTATİSTİKLERİ IO'YU AYARLADIĞINIZDA, SEGMENT ELEME İŞLEMİNİ GERÇEK ZAMANLI OLARAK GÖREBİLİRSİNİZ. Segment eleminasyonunun gerçekleştiğini belirtmek için aşağıdaki gibi bir çıktı olup olmadığını kontrol edin. Satır grupları sütun kesimlerinden oluşur, bu nedenle segmentlerin ortadan kaldırılmasını gösterebilir. Aşağıdaki SET STATISTICS IO çıktı örneğinde yaklaşık 83% veri sorgu tarafından atlandı:

...
Table 'FactResellerSalesPartCategoryFull'. Segment reads 16, segment skipped 83.
...

İlgili içerik

  • Last updated on