Я уже долго работаю с MS SQL Server и только несколько раз приходилось использовать подсказки оптимизатора базы данных, чтобы указать, как более эффективно выполнять запрос. На этой неделе сразу дважды SQL Server лоханулся.
Решение о том, какой план выполнения выбирать и как обрабатывать результаты зависит от корректности статистики. Я попробовал ее обновить, но всё равно, сервер продолжал заниматься фигней.
Первый раз у меня выполнялось два небольших запроса к таблице и они джоинились вместе. Причем оба из них выполнялись быстро, но когда нужно было объединить результат, сервер просто умирал. Я запустил просмотр плана выполнения и увидел, сто сервер выбрал Left loop join в качестве джоина. Это значит, что сервер выполнял первый запрос и для каждой строки результата выполнял второй запрос. Таблицы огромные и не смотря на то, что первый из запросов возвращал всего 100 строк, результат был плачевный, потому что loop выполнялся 100 раз.
Похоже мало кто знает, что серверу можно подсказывать правильный вариант объединения. Это нужно делать только в самом крайнем случае, потому что в 99% случаев MS SQL Server выбирает всё же хорошие планы. Но если нет, то можно подсказать. В моем случае простая замена left join на left merge join спасла мне жизнь, потому что когда два вопроса выполняются быстро, их выгоднее выполнить по отдельности и потом результат смерджить.
Возможные варианты подсказок - merge, hash или loop.
А ты знал о подсказках? Как часто используешь в своей работе.
Понравилось? Кликни Лайк, чтобы я знал, какой контент более интересен читателям. Заметку пока еще никто не лайкал и ты можешь быть первым
Лично я - нет, ведь только месяц как начала изучать вашу книгу по MS SQL. Уверен, что дойду и до оптимизации запросов, например, и в таких случаях, как у вас. Хочется сказать вам спасибо за этот труд!) Михаил, а не будет ли обновления по T-SQL? Допустим как это было с Библией Delphi или C#?
Обновления к сожалению не будет, ее даже допечатывать не стали, потому что продажи были очень слабыми
Я знаю о хинтах. Правда мы используем Oracle. Хинтами пользуюсь только при тестах, что бы посмотреть планы запросов по разным индексам. В бою насильно не указываем БД как ей выполнять запрос.
Михаил, пишите больше книг! Вот купил бы вашу книгу по разработке в IOS.
Я часто использую merge если джойнятся две большие таблички,
смотрю чисто визуально по времени выполнения, если время выполнения больше в разы c merge чем без него, то ставлю merge.
То же самое касаемо loop join, если одна табличка маленькая, например, справочник, а другая очень большая.
Принудительно hash join Никогда не вызываю, он по умолчанию почти всегда...
Хотите найти еще что-то интересное почитать? Можно попробовать отфильтровать заметки на блоге по категориям.
Программист, автор нескольких книг серии глазами хакера и просто блогер. Интересуюсь безопасностью, хотя хакером себя не считаю
Copyright © 2024 Михаил Флёнов. Тираж 1 штука. Отпечатано на ноутбуке. А за права отвечаю, или постараюсь.
А здесь еще и копирайт поставлю: Professional Web Development.
На сайте используются Cookie. Если вы из ЕС или Калифорнии США, то вы должны согласиться с их использованием - Согласен. Если вы из нормальной страны, то вам пох.
