Оптимізація запитів sql server. Частина iv

Оцінки оптимізації для невідомих для операторів BETWEEN і LIKE

Відео: Сергій Міхальов - Оптимізація SQL-запитів, частина 1

При використанні предиката BETWEEN жорстко задані припущення залежать від сценарію і застосовуваної CE. У старих CE у всіх випадках використовується оцінка 9%. Це демонструє наступний запит. Прапор трасування 9481 запиту використовується, щоб застосувати стару CE.

DECLARE @FromQty AS INT = 40, @ToQty AS INT = 41-SELECT ProductID, COUNT (*) AS NumOrdersFROM Sales.SalesOrderDetailWHERE OrderQty BETWEEN @FromQty AND @ToQtyGROUP BY ProductIDOPTION (QUERYTRACEON 9481) -

Відео: 4. Проектування СУБД. Оптимізація запитів та індексування | Технострим

План для цього запиту показаний на малюнку вище. Оцінка 0,09 * 121317 = 10918,5.

У новій CE задіяні різні оцінки при застосуванні констант і відсутньої гистограмме і при використанні змінних або параметрів з відключеним прослуховуванням. У першому випадку використовується оцінка 9% - у другому - оцінка 16,4317%. Нижче наводиться приклад використання констант. Обов`язково видаліть будь-яку існуючу статистику для стовпця і відключіть автоматичне створення статистики, як показано вище, перед виконанням тесту і включіть після його завершення.

DECLARE @FromQty AS INT = 40, @ToQty AS INT = 41-SELECT ProductID, COUNT (*) AS NumOrdersFROM Sales.SalesOrderDetailWHERE OrderQty BETWEEN @FromQty AND @ToQtyGROUP BY ProductIDOPTION (QUERYTRACEON 9481) -

Я отримав такий же план, як на малюнку вище, з оцінкою 9%.

Нижче наводиться приклад, який демонструє застосування змінних (то ж поведінку, що і при використанні параметрів з відключеним прослуховуванням):

DECLARE @FromQty AS INT = 40, @ToQty AS INT = 41-SELECT ProductID, COUNT (*) AS NumOrdersFROM Sales.SalesOrderDetailWHERE OrderQty BETWEEN @FromQty AND @ToQtyGROUP BY ProductID-

Я отримав план, наведений на малюнку вище, показує оцінку 16,4317%.

При використанні предиката LIKE у всіх сценаріях оптимізації для невідомого як в старих, так і в нових CE застосовується оцінка 9%. Нижче наведено прикладі використанням локальних змінних:

DECLARE @Carrier AS NVARCHAR (50) = N`4911-403C -% `- SELECT ProductID, COUNT (*) AS NumOrdersFROM Sales.SalesOrderDetailWHERE CarrierTrackingNumber LIKE @CarrierGROUP BY ProductID-

Ви побачите ту ж оцінку 9%, як показано на малюнку «План, що показує оцінку 9%», хоча в даному випадку дійсне число рядків 12, а раніше було 3.


При використанні оператора = розрізняють три основних випадку:
• унікальний стовпець;
• неунікальний стовпець і доступна щільність;
• неунікальний стовпець і недоступна щільність.

Якщо фільтрується стовпець унікальний (для нього визначені унікальний індекс, обмеження PRIMARY KEY або UNIQUE), то оптимізаторові відомо, що збігів не може бути більше одного, тому оцінка дорівнює 1. Нижче наводиться запит, який демонструє цей випадок:

DECLARE @rowguid AS UNIQUEIDENTIFIER = `B207C96D-D9E6-402B-8470-2CC176C42283`-SELECT * FROM Sales.SalesOrderDetailWHERE rowguid = @ rowguid-

Відео: Microsoft M10774 Створення запитів в Microsoft SQL Server 2012 day1

На малюнку вище показаний план для цього запиту з оцінкою 1.

Якщо стовпець не унікальний і оптимізатора доступна інформація про щільність (середній відсоток для окремого значення), то оцінка ґрунтується на щільності. Якщо не відключено автоматичне створення статистики або для стовпця сформований індекс, то ця інформація буде доступна оптимізатора. Щоб продемонструвати це, спочатку переконайтеся, що автоматичне створення статистики включено, виконавши наступний програмний код:

ALTER DATABASE AdventureWorks2014 SET AUTO_CREATE_STATISTICS ON-

Потім виконайте наступний запит:

DECLARE @Qty AS INT = 1-SELECT ProductID, COUNT (*) AS NumOrdersFROM Sales.SalesOrderDetailWHERE OrderQty = @QtyGROUP BY ProductID-