2015-08-16 4 views
2

Я изучаю, чтобы стать администратором базы данных, делая это, я хочу узнать немного больше о настройке запросов. Большинство из них я могу понять, но я хотел понять, почему эти два запроса имеют один и тот же план выполнения, даже написанный двумя разными способами. Они основаны на базе данных adventureworks2012lt.Тот же план выполнения?

select productnumber, name, listprice 
from saleslt.product 
where productnumber like 'bk-[a-q,s-z]%' and productnumber like '%-[0-9][0-9]' 


SELECT ProductNumber, Name, ListPrice 
FROM SalesLT.Product 
WHERE ProductNumber LIKE 'BK-[^R]%-[0-9][0-9]'; 

Я не могу размещать фотографии еще потому, что моя репутация не высока, но достаточно :(

+0

Они одинаково логичны: (затронуто 54 ряда) Таблица «Продукт». Число сканирования 1, логическое считывание 103, физическое чтение 0, чтение вперед 0, логическое считывание 0, логическое чтение 0, считывание с чтением 0, считывание с чтением 0 ... (затрагивается 1 ряд (строк)) (54 ряда (s)) Таблица «Продукт». Число сканирования 1, логическое считывание 103, физическое считывание 0, чтение вперед 0, логическое считывание 0, логическое чтение 0, чтение с чтением 0, считывание с чтением 0 ... (затронуты 1 строка) –

+0

Я просто скажу , Механизм SQL-сервера более умный, чем вы думаете. –

+0

Два типа поиска по номеру продукта с wild card, и вы удивлены, что он имеет тот же план выполнения? – Paparazzi

ответ

0

Представьте, что вы вручную просматривали каталог продукции, ищете продукт Номер шаблона вы указали. Эти продукты не являются сортируются в любом порядке. Какой выбор у вас есть, кроме как просматривать все продукты и сопоставлять их один за другим? У вас нет индекса на ProductNumber. У SQL Server нет выбора, кроме как выполнить сканирование таблицы, чтобы найти соответствующие строки.

Но что произойдет, если вы добавите индекс в ProductNumber? Результат был бы таким же в любом случае , Шаблоны, начинающиеся с %, не могут использовать индекс. Таким образом, ваш первый запрос переместится в диапазон в индексе, который начинается с BK. И так будет ваш второй запрос.

Новички одержимы тем, что делают вещи эффективными. Со временем вы научитесь оставлять вещи на SQL Server. Вы должны только беспокоиться о вещах, когда они становятся проблемой. Единственным исключением является курсор. Если вы думаете об использовании курсоров для решения проблемы, это неправильный подход в 90% случаев.

+0

Несколько вещей, которые я хотел бы добавить: 1) База данных имеет уникальный, некластеризованный индекс, расположенный в столбце номер продукта. Это означает, что вы должны быть более эффективными при правильном выполнении второго запроса? Поскольку вы не можете использовать индекс, когда подобное предложение начинается с «%». 2) Я не считаю, что вы должны оставлять вопросы в покое, пока они не станут проблемой. В конце концов, вы можете создать эффективный план выполнения для одного запроса, и когда вы измените переменные, это будет страшный план выполнения. (Плохой охват кода AKA и обнюхивание параметров) –

+1

«Преждевременная оптимизация - это корень всех злых дел» - Дональд Кнут. Знайте хорошие практики для написания хорошего запроса, а затем оставьте остальную часть базы данных. Всегда будут случаи, когда ваши запросы замедляются до уровня craw. Меня не волнует, если запрос перескочит с 1 до 2 с (увеличение на 100%), пока бизнес не скажет, что это проблема. Я могу лучше потратить свои силы в другом месте. –

+0

В первую очередь: да, второе условие в первом запросе - SARGEABLE, но первое - это. Таким образом, оба запроса перейдут в диапазон, начинающийся с BK, и продолжите оттуда. Что происходит дальше, действительно сложно сказать: эффективнее ли оценивать 2 простых условия или 1 сложное состояние? Чтобы получить определенный ответ, вам нужно сравнить его по миллионам строк, и тогда разница может быть слишком мала, чтобы иметь значение вообще. –