Будет ли работать этот метод настройки SQL?

Question

Я только что прочитал это сообщение в блоге и, вкратце, он говорит, что если SQL-сервер не выполняет достаточно хороших планов построения запросов, то последнее, что вы хотите сделать, это начать с самого начала кодирование вещей. Итак, это заставило меня задуматься; Как вы могли бы "жестко кодировать" вещи без жесткого кода. (Да, я так думаю.)

является следующим; 1) возможно, 2) хорошая идея и 3) есть ли инструменты, которые помогут администраторам баз данных сделать это?

У вас медленный запрос, и по какой-то причине вам не нравится план запроса, который выбирает ваша СУБД. Таким образом, вы начинаете играть с ним (на сервере разработки), заставляя разные вещи, пока не получите план, который лучше. Затем вы пытаетесь декомпозировать процесс принятия решений в СУБД, чтобы выяснить, почему она не выбрала эту, а затем перепроектировать то, что потребуется, чтобы заставить ее выбрать лучшую.

---

Редактировать: Первые ответы, кажется, отвечают на несколько иной вопрос, чем я пытался задать.

Ситуация: у вас есть запрос, который недостаточно быстр, но вы думаете, что можете сделать его быстрее (на данный момент) путем жесткого кодирования частей плана запроса. Однако вы не хотите делать это в prod по любой причине.

(Предлагаемое) решение: Создание и тестирование жестко закодированных планов запросов. Когда вы найдете достаточно быстрое приложение, попробуйте и откажитесь от того, на что смотрит СУБД (статистика и т. Д.), Когда она решит не использовать лучший план. Когда у вас есть это, используйте это как руководство для того, что настраивать.

Вопрос: Является ли описанный выше практический способ выполнения задачи? Достаточно ли их ручек, чтобы включить его? Есть ли у них какие-либо инструменты, которые показывают, что данные использовались для принятия решений по плану запроса?

Answer 1

Эта страница поддержки Microsoft указывает на то, как создать базу данных только для статистики. Не беспокойтесь о разрыве чего-либо, но с текущей статистикой индекса, чтобы иметь возможность провести некоторый анализ плана запроса. Это может помочь.

Answer 2

Прежде всего, как отмечает комментатор в сообщении, на которое вы ссылаетесь, здесь происходит немного FUD - суммируя для тех, кто не хочет нажимать на ссылку: «Все может пойти плохо. .. купи мою книгу! "

Второе, что вы перечислите в своем вопросе, это не жесткое кодирование, а использование жесткого кодирования, чтобы выяснить лучшие способы работы с БД. Мне кажется, это нормально. До тех пор, пока вы не оставите жестко закодированные подсказки, все должно быть в порядке, сервер SQL все равно может изменять оптимизацию при изменении данных.

Answer 3

Тот факт, что вы спрашиваете (в большинстве случаев, кроме вашего, я уверен), предполагает, что у вас недостаточно опыта работы с SQL Server, чтобы иметь возможность хорошо управлять оптимизатором. Я и мастера SQL Server, которых я знаю (некоторые из них делают это достаточно эффективно, но, как я понимаю, всегда в крайних случаях), скажут, что в конечном итоге вы найдете лучший способ написания вашего запроса и Ваши подсказки не будут полезны. Но YMMV, как обычно.

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

Подсказки и режимы блокировки - это две настройки, с которыми люди могут начать слишком быстро связываться, когда у них заканчиваются другие идеи. С оптимизатором особенно важно знать, «почему» то, чего вы ожидаете, не происходит, и «почему» внесенные вами изменения вызвали эффект, который вы наблюдали.

Answer 4

Если оптимизатор выбирает план, который вы не ожидаете, это, как правило, признак того, что базовые структуры данных сформированы неправильно. Индекс может отсутствовать. Вы можете пытаться объединить два столбца с разными типами данных. Вы можете искать или присоединяться к сложному сгенерированному столбцу. Я действительно видел такие вещи раньше:

SELECT *
FROM
  t1
  INNER JOIN t2 ON LTRIM(RTRIM(t1.code)) = LTRIM(RTRIM(t2.code))

Это требует улучшения базовых структур данных!

Answer 5

Вы можете жестко задавать имена индексов и советы по оптимизации в своем запросе.

Вот один преобразованный запрос и возможное преобразование

SELECT Customers.CompanyName, Sum (Orders.TotalAmount) As TotalAmount
FROM Customers
    INNER JOIN Orders
        ON Customers.ID = Orders.CustomerID
WHERE Customer.Country IN ('USA', 'Canada')

Теперь для жестко закодированных подсказок

SELECT Customers.CompanyName, Sum (Orders.TotalAmount) As TotalAmount

FROM Customers WITH (NOLOCK, IdxCountry)
    INNER LOOP JOIN Orders (TABLOCK, IdxCustomerOrders)
        ON Customers.ID = Orders.CustomerID

WHERE Customer.Country IN ('USA', 'Canada')

Второй запрос вынуждает план выполнения использовать следующее

• Клиенты имеют NOLOCK и должны использовать Index IDXCountry
• Orders имеет TABLOCK и должен использовать Index IdxCustomersOrders
• Подсказка к соединению теперь LOOP

Можете ли вы софткод Индекс и Советы по присоединению? Не как часть обычного запроса. Однако для этой цели вы можете создать и выполнить динамический SQL.

SQL Server очень хорош в оптимизации запросов, и чем больше вы читаете об этом, тем лучше вы будете писать запросы. Я думаю, вы должны прочитать об оптимизации запросов и настройке индекса, чтобы лучше это понять

Каковы ваши наиболее распространенные оптимизации SQL?

Как узнать, как настроить индекс SQL Server?

Чтобы ответить на ваши вопросы

1. Si Si. Возможно жесткое кодирование без жесткого кодирования.
2. Не стоит делать это самостоятельно, если вы не очень регулярно следите за производительностью и выполнением.
3. Больше, чем инструменты для администраторов баз данных, это вопрос знания SQL Server, который поможет. Узнайте больше об оптимизации запросов, и она автоматически доставит вас туда.

Answer 6

Да, вы должны выяснить, почему он придумал неоптимальный план. Это не должно быть ударом или промахом. Вы должны вручную выяснить лучший план, искать различия и затем причину. Число по причине плохих планов является неверным расчетом количества элементов. Скос убьет тебя.

** Вот как вы это сделаете в Oracle, вы можете сказать мне, как SQL Server работает с переменными связывания **

Скажем, у вас есть столбец Да / Нет и индекс для столбца, потому что он часто оказывается в предложениях where. Из 10000 строк один - да, остальные 99,99% строк - нет.

Если вы напишите свой запрос с переменной связывания, как в: (Параметризованный запрос на SS говорит)

ВЫБРАТЬ * ИЗ таблицы ГДЕ yn_col =: 1

Оптимизатор не может кэшировать отдельный план для этого запроса. Если вы спросите «Да», тогда индекс подходит, FTS не будет слишком плохим. Если вы спросите «Нет», тогда будет подходящим FTS, но сканирование индекса с последующим доступом к таблице по идентификатору строки будет кошмаром.

У вас есть два варианта, зафиксировать план в FTS, чтобы всегда было одно и то же время. Для конечного пользователя это выглядит последовательным. Но если вы хотите воспользоваться индексом, вам нужно записать его как два запроса без его параметризации, чтобы оптимизатор увидел это как «Да» и «Нет», а если в значениях столбцов есть гистограмма, мощность будет правильно рассчитана.

Здесь у вас нет другого выбора, если только SQL Server не имеет возможности кэшировать привязку к чувствительным к переменным планам, как Oracle добавил в 11g.