SQL Server basit bijection üzerinde dizin kullanamıyor

Bu başka bir sorgu optimizer bilmecesidir.

Belki sadece sorgu optimize edicileri aşırı tahmin ediyorum, ya da belki bir şey eksik - bu yüzden orada koyuyorum.

Basit bir masam var

CREATE TABLE [dbo].[MyEntities](
  [Id] [uniqueidentifier] NOT NULL,
  [Number] [int] NOT NULL,
  CONSTRAINT [PK_dbo.MyEntities] PRIMARY KEY CLUSTERED ([Id])
)

CREATE NONCLUSTERED INDEX [IX_Number] ON [dbo].[MyEntities] ([Number])

bir indeks ve orada bin sıra ile Number0, 1 ve 2 değerlerinde eşit olarak dağıtılır.

Şimdi bu sorgu:

SELECT * FROM
    (SELECT
        [Extent1].[Number] AS [Number],
        CASE
        WHEN (0 = [Extent1].[Number]) THEN 'one'
        WHEN (1 = [Extent1].[Number]) THEN 'two'
        WHEN (2 = [Extent1].[Number]) THEN 'three'
        ELSE '?'
        END AS [Name]
        FROM [dbo].[MyEntities] AS [Extent1]
        ) P
WHERE P.Number = 0;

IX_Numberbeklendiği gibi bir endeks arayışı yapar .

Eğer nerede cümlesi

WHERE P.Name = 'one';

ancak bir tarama haline gelir.

Vaka cümlesi açık bir şekilde bir iki yönlüdür, bu nedenle teoride birinci sorgu planını ikinci sorgudan çıkarmak için bir optimizasyon mümkün olmalıdır.

Aynı zamanda sadece akademik değil: Sorgu, enum değerlerini ilgili kolay adlarına çevirerek esinlenmiştir.

Sorgu optimize edicilerden (ve özellikle Sql Server'da bir) ne olacağını bilen birinden duymak istiyorum: Sadece çok fazla bekliyorum?

Daha önce bir sorgu biraz varyasyon bir optimizasyon aniden ortaya geleceğini durumlarda vardı soruyorum.

Sql Server 2016 Developer Edition kullanıyorum.

Sadece çok mu fazlasını bekliyorum?

Evet. En azından ürünün mevcut sürümlerinde.

SQL Server CASEdeyimi ayırmayacak ve hesaplanan sütunun sonucunun 'one'o zaman [Extent1].[Number]olması gerektiğini bulmak için tersine mühendislik 0.

Sarsılmak için tahminlerinizi yazdığınızdan emin olmanız gerekir. Hangi hemen hemen her zaman formda olmasını içerir. basetable_column_name comparison_operator expression.

Küçük sapmalar bile kırılganlığı bozar.

WHERE P.Number + 0 = 0;

basitleştirmek, CASEifadeden daha basit olsa da, bir dizin araması kullanmaz .

Bir dize adı üzerinde arama yapmak ve numaraya bir arama almak istiyorsanız, ad ve sayıları içeren bir eşleme tablosuna ihtiyacınız olacak ve sorguda ona katılacaksınız, planın eşleme tablosunda bir arama ve ardından ilişkili bir arama olabilir. üzerinde [dbo].[MyEntities]dönen numarası ile ilk ararlar.

Numaralandırmanızı vaka bildirimi olarak yansıtmayın. Aşağıdaki gibi türetilmiş bir tablo olarak yansıtın:

SELECT * FROM
   (SELECT
      [Extent1].[Number] AS [Number],
      enum.Name
   FROM
      [dbo].[MyEntities] AS [Extent1]
      LEFT JOIN (VALUES
         (0, 'one'),
         (1, 'two'),
         (2, 'three')
      ) enum (Number, Name)
         ON Extent1.Number = enum.Number
   ) P
WHERE
   P.Name = 'one';

Daha iyi sonuçlar alacağınızdan şüpheleniyorum. ( ?Bu, büyük olasılıkla performans kazanımlarına engel olacağından, eksik olduğunda Adı dönüştürmedim . Ancak, WHEREyüklemi enumtabloya koymak için yan tümceyi yan tümceye taşıyabilir veya iki sütunu iç sorgu, biri yüklem için ve diğeri görüntüleme için; burada yüklem, NULLeşleşen numaralandırma değeri olmadığındadır.)

Yine de, [Extent1]orada nedeniyle , Entity Framework veya Linq-To-SQL gibi bir ORM kullandığınızı tahmin ediyorum . Böyle bir projeksiyonu yerel olarak nasıl gerçekleştireceğiniz konusunda size rehberlik edemem, ancak farklı bir teknik kullanabilirsiniz.

Bir projemde, enum değerlerini veritabanına birleştiren özel bir derleme sınıfıyla, kod enum değerlerini veritabanındaki gerçek tablolara yansıttım. (Enum değerlerinizi açıkça listelemeniz gereken kurallara uymanız, tablolarınızı gözden geçirmeden hiçbir zaman silmemeniz ve asla değiştiremezsiniz, ancak mevcut kurulumunuzda bunun en azından bir kısmını gözlemlemeniz gerekir) .

Şimdi, Identifierbirçok farklı beton alt sınıfı olan bir numaralandırma sınıfını kullanıyordum, ancak sade bir vanilya enum ile yapılamamasının bir nedeni yok. İşte bir örnek kullanım:

new EnumOrIdentifierProjector<CodeClassOrEnum, PrivateDbDtoObject>(
   _sqlConnector.Connection,
   "dbo.TableName",
   "PrimaryKeyId",
   "NameColumnName",
   dtoObject => dtoObject.PrimaryKeyId,
   dtoObject => dtoObject.NameField,
   EnumerableOfIdentifierOrTypeOfEnum
)
   .Populate();

Veritabanı değerlerini yazmak ve okumak için gerekli tüm bilgileri aktardığımı görebilirsiniz. (Geçerli istek tüm mevcut değerleri içermeyebilir bir durum vardı, bu yüzden veritabanından yanı sıra şu anda yüklü kümesi herhangi bir ek döndürmek gerekiyordu. Ben de veritabanı numaralarını atamasına izin, bir numaralandırma için muhtemelen olmaz bunu istiyorum.)

Fikir, başlangıçta sadece bir kez okunan / yazılan bir tablonuz olduğunda, tüm numaralandırma değerlerine güvenilir bir şekilde sahip olacak, diğer tablolar gibi ona katılıp performansın iyi olması gerektiğidir.

Umarım bu fikirler bir gelişme sağlamanız için yeterlidir.

Soruyu genel olarak optimize edicilerle ilgilendiğiniz, ancak SQL Server için özel bir ilgiyle yorumladınız. Senaryonuzu db2 LUW V11.1 ile test ettim:

]$ db2 "create table myentities ( id int not null, number int not null )"
]$ db2 "create index ix_number on myentities (number)"
]$ db2 "insert into myentities (id, number) with t(n) as ( values 0 union all select n+1 from t where n<10000) select n, mod(n,3) from t"

DB2'deki iyileştirici ikinci sorguyu birincisine yeniden yazar:

Original Statement:
------------------
SELECT 
  * 
FROM 
  (SELECT 
     number,

   CASE 
   WHEN (0 = Number) 
   THEN 'one' 
   WHEN (1 = Number) 
   THEN 'two' 
   WHEN (2 = Number) 
   THEN 'three' 
   ELSE '?' END AS Name 
   FROM 
     MyEntities
  ) P 
WHERE 
  P.name = 'one'


Optimized Statement:
-------------------
SELECT 
  Q1.NUMBER AS "NUMBER",

CASE 
WHEN (0 = Q1.NUMBER) 
THEN 'one' 
WHEN (1 = Q1.NUMBER) 
THEN 'two' 
WHEN (2 = Q1.NUMBER) 
THEN 'three' 
ELSE '?' END AS "NAME" 
FROM 
  LELLE.MYENTITIES AS Q1 
WHERE 
  (0 = Q1.NUMBER)

Plan şöyle görünüyor:

Access Plan:
-----------
        Total Cost:             33.5483
        Query Degree:           1


      Rows 
     RETURN
     (   1)
      Cost 
       I/O 
       |
      3334 
     IXSCAN
     (   2)
     33.1861 
     4.66713 
       |
      10001 
 INDEX: LELLE   
    IX_NUMBER
       Q1

Diğer optimizatörler hakkında fazla bir şey bilmiyorum, ancak DB2 optimizatörünün rakipler arasında bile oldukça iyi olduğu hissine kapıldım.

Bu özel sorguda, bir CASEifade bile almak çok saçma . Belirli bir vakayı filtreliyorsunuz! Belki de bu, verdiğiniz belirli örnek sorgunun sadece bir ayrıntısıdır, ancak değilse, eşdeğer sonuçlar almak için bu sorguyu yazabilirsiniz:

SELECT
    [Extent1].[Number] AS [Number],
    'one' AS [Name]
FROM [dbo].[MyEntities] AS [Extent1]
WHERE [Extent1].[Number] = 0;

Bu size tam olarak aynı sonuç kümesini verecektir ve zaten bir CASEifadede zaten sabit kodlama değerleri olduğundan, burada herhangi bir sürdürülebilirliği kaybetmezsiniz.