Как ускорить присоединение

Question

Я использую SQL Server 2008r2.У меня проблема с возвратом данных пользователю из-за массивных объединений (например, мне нужно сделать 5 внутренних + 6 левых объединений в одном запросе (обычно это tvfs, иногда таблицы). Это занимает слишком много времени.)

Каковы обходные пути для этой проблемы?Должен ли я денормолизировать свою базу данных?Как лучше всего избегать огромного количества объединений?

Answer 1

Мне нужно увидеть SQL, чтобы устранить неполадки, но вот несколько вещей, которые я делаю, когда извлекаю результаты, которые имеют чрезвычайно высокий спрос:

1. Используйте ваши инструменты.Показать примерный план выполнения может выявить некоторые очевидные капризы в вашей логике.

2. Научитесь любить «там, где есть» и «иметь».Вы можете свести к минимуму фокус и область применения, квалифицируясь творческими способами, которые не требуют жесткого ввода-вывода.Это более верно для подзапросов, чем для объединений, но я добавляю условие для каждого внешнего объединения, которое мне нужно.

3. Самое главное, ИМО, не бойтесь ставить свои результаты.Иногда вам нужно обрабатывать миллиарды / триллионы транзакций с миллионами записей, и то, что занимает часы с объединениями, можно выполнить за несколько минут или секунд путем поэтапной обработки.Если вам нужны только x% из ваших верхних 2 или 3 таблиц, зачем объединять каждую запись сверху вниз?Иногда это слишком много накладных расходов.Потяните ваш самый простой набор результатов к таблице этапов (или временному, независимо от того, что вам нужно), индексируйте его и затем переходите к следующему фрагменту.Это обычно экономит мне память.

4. Используйте CTE, когда можете.Тем не менее, по моему опыту, они деградируют за пределы определенной точки.Хорошо для вспомогательных таблиц, но не для серьезного объема.

Будьте изобретательны в своих комбинациях.Я буду использовать эти существующие предложения на этапе 1 (чтение таблиц a, b и c), чтобы вернуть только те записи, которые также существуют в таблицах d, e и f.

Многие советы экспертов по SQLне основан на VLDB - он основан на схемах типа Клиент, Заказы, Демографический тип.

Работают ли эти хранимые процессы самостоятельно?

Answer 2

Вот хороший (слишком упрощенный) пример постановки:

Допустим, вы хотели найти всех людей с высоким риском в вашем городе (возможно, вам будет интересно). У вас есть телефонная компания дБ (национальная), проиндексированная по штату, городу, фамилии, имени, адресу и ФБР дБ (глобальная), проиндексированная по фамилии, имени, стране, региону, адресу. Допустим, в базе данных ФБР есть несколько записей для каждого человека из-за нескольких прошлых адресов.

Вы можете объединить два дБ на общих элементах и ​​затем квалифицировать свои критерии. Или же... Выберите RecordID с телефона как P1 Где State = 'MyState' и City = 'MyCity' и существует (выберите 1 От TheMan как M1 Где M1.Last = P1.Last и M1.First = P1.First и M1.Risk> 80)

Теперь у меня есть небольшой набор записей для квалификации и небольшой набор результатов для работы. Оттуда я могу пойти получить детали. Это хороший кандидат на CTE, и я мог бы пробить дюжину дыр в логике, но это иллюстрирует концепцию. Если вы введете M1.Risk (неиндексированное поле) в уравнение с полным объединением, вы заставляете SQL Server планировать его в определенных ситуациях. Не обязательно здесь, но поскольку ваша логика становится более сложной, и в игру вступают последующие неиндексированные критерии.