Сервер Sql не вдається використовувати індекс для простого біекціонування

Це ще одна загадка оптимізатора запитів.

Можливо, я просто завищую оптимізатори запитів, або, можливо, мені щось не вистачає - тому я викладаю його там.

У мене проста таблиця

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])

з індексом і кількома тисячами рядків, Numberрозподілених рівномірно у значеннях 0, 1 і 2.

Тепер цей запит:

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_Numberяк можна було б очікувати.

Якщо пункт де

WHERE P.Name = 'one';

однак це стає скануванням.

Заява "регістр" - це, очевидно, бікс

Це також не є суто академічним: запит надихається перекладом значень enum у відповідні дружні імена.

Мені хотілося б почути від того, хто знає, чого можна очікувати від оптимізаторів запитів (а саме від сервера Sql): Я просто очікую занадто багато?

Я запитую, як у мене були випадки, коли деякі незначні зміни запиту зробили б оптимізацію раптом.

Я використовую Sql Server 2016 для розробників.

Я просто надто чекаю?

Так. Принаймні в сучасних версіях продукту.

SQL Server не вибере окремо CASEоператор і реверсує його, щоб виявити, що якщо результат обчисленого стовпця, 'one'то [Extent1].[Number]повинен бути 0.

Вам потрібно переконатися, що ви пишете свої предикати, щоб вони були зручними. Що майже завжди передбачає його перебування у формі. basetable_column_name comparison_operator expression.

Навіть незначні відхилення порушують працездатність.

WHERE P.Number + 0 = 0;

не використовував би індекс пошуку, навіть якщо спростити його навіть простіше, ніж CASEвираз.

Якщо ви хочете здійснити пошук за назвою рядка та отримати номер пошуку, вам знадобиться таблиця відображення з іменами та номерами та приєднатись до нього у запиті, тоді план може мати пошук на таблиці відображення з наступним співвіднесеним пошуком далі [dbo].[MyEntities]з номером, повернутим з першого пошуку.

Не проектуйте свою перерахунок як випадок справи. Проектуйте його як похідну таблицю так:

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';

Я підозрюю, що ви отримаєте кращі результати. (Я не конвертував Ім'я у ?відсутнє, оскільки це, ймовірно, заважатиме підвищити продуктивність. Однак, ви можете перемістити WHEREпункт у зовнішній запит, щоб помістити предикат на enumтаблицю, або ви могли повернути два стовпці з таблиці внутрішній запит, один для предиката і один для відображення, де предикат - це NULLколи немає відповідного значення перерахунку.)

Але я здогадуюсь, що через те [Extent1], що ви там, ви використовуєте ORM, такий як Entity Framework або Linq-To-SQL. Я не можу орієнтувати вас, як реально виконати таку проекцію, але ви можете використовувати іншу техніку.

В одному з моїх проектів я відображав значення перерахунку коду в реальних таблицях бази даних, через клас побудови на замовлення, який об'єднав значення enum у базу даних. (Ви повинні дотримуватися правила, згідно з яким ви повинні чітко перелічити свої значення enum. Ніколи не можна видалити жодну, не переглядаючи ваші таблиці, і ніколи, ніколи не змінювати їх, хоча вам вже доводиться дотримуватися принаймні дещо з цього при вашому поточному налаштуванні) .

Тепер я використовував безліч Identifierбазового класу, який містить багато різних конкретних підкласів, але немає причин, щоб це не було можливо зробити з простою ванільною перерахункою. Ось приклад використання:

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

Видно, що я передав всю необхідну інформацію для того, щоб записати та прочитати значення бази даних. (У мене була ситуація, коли поточний запит може не містити всіх існуючих значень, тому необхідно повернути будь-які додаткові дані з бази даних, а також завантажений на даний момент набір. Я також дав базі даних присвоювати ідентифікатори, хоча для перерахунку ви, ймовірно, не хотіли б хочу цього.)

Ідея полягає в тому, що коли у вас є таблиця, яка читається / записується лише один раз при запуску, яка надійно матиме всі значення перерахунку, ви просто приєднаєтесь до неї, як і будь-яка інша таблиця, і продуктивність повинна бути хорошою.

Я сподіваюся, що цих ідей вам достатньо для покращення.

Я трактую питання як те, що вас цікавлять оптимізатори в цілому, але з особливим інтересом для SQL Server. Я перевірив ваш сценарій із db2 LUW V11.1:

]$ 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 переписує другий запит на перший:

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)

План виглядає так:

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

Я не знаю багато про інші оптимізатори, але я відчуваю, що оптимізатор DB2 вважається досить хорошим навіть серед конкурентів.

У цьому конкретному запиті досить нерозумно навіть мати CASEзаяву. Ви фільтруєте до одного конкретного випадку! Можливо, це лише деталь конкретного прикладу запиту, який ви подали, але якщо ні, ви можете написати цей запит, щоб отримати еквівалентні результати:

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

Це дасть вам точно такий же набір результатів, і оскільки у вас вже є важкі значення кодування в CASEоператорі, ви тут не втрачаєте жодної ремонтопридатності.