Улучшение производительности на представлении с БОЛЬШИМ КОЛИЧЕСТВОМ [закрытых] соединений
У меня есть представление, которое использует 11 внешних объединений и два внутренних объединения для создания данных. Это приводит к более чем 8 миллионам строк. Когда я провожу подсчет (*) на таблице, требуется приблизительно 5 минут для выполнения. Я в замешательстве относительно того, как улучшить производительность этой таблицы. У кого-либо есть какие-либо предложения на том, где начать? Кажется, существуют индексы на всех столбцах, которые присоединяются (хотя некоторые - составной объект, не уверенный, если это имеет значение...),
Любая справка ценится.
5 ответов
Это сложный вариант, со сложным представлением у вас также есть потенциальные взаимодействия с запросами к представлению, поэтому гарантировать разумную производительность будет довольно сложно. Внешние соединения в представлениях (особенно сложные) также могут вызывать проблемы для оптимизатора запросов.
Один из вариантов - материализовать представление (называемое «индексированными представлениями» в SQL Server). Однако вам может потребоваться следить за производительностью обновления, чтобы убедиться, что оно не вызывает слишком больших накладных расходов. Кроме того, внешние соединения в материализованном виде могут препятствовать обновлению в реальном времени; если вам это нужно, то вам, возможно, придется заново реализовать представление как денормализованную таблицу и поддерживать данные с помощью триггеров.
Другой возможностью было бы проверить, можно ли разбить представление на два или три более простых представления, возможно, материализуя некоторые но не все на вид. Таким образом может быть проще материализовать часть представления и добиться производительности системы.
Может быть, некоторые из таблиц, которые вы пытаетесь (внешние) объединить, не пересекаются? Если да, рассмотрите возможность создания хранимой процедуры вместо представления и создайте что-то вроде этого:
select ...
в # set1
от T1 слева присоединиться к T2 слева присоединиться ...
где ...
выберите ...
в # set2
от T3 слева присоединиться к T4 слева присоединиться ...
где ...
...
select ... from # set1 left join # set2 left join ...
Таким образом, вы можете избежать обработки большого количества данных. Когда вы выполняете внешние соединения, оптимизатор часто не может переместить выделение вниз в дереве синтаксического анализа запроса (если бы это было сделано, вы бы не получили строки с нулями, которые вам, вероятно, нужны)
Конечно, вы не можете создать запрос с объединением с сохраненным процедура. Это только основная идея, которую вы можете использовать.
ваша основная посылка неверна. иметь представление, которое возвращает 8 миллионов строк, - не лучшая идея, потому что на самом деле вы ничего не можете сделать с таким большим количеством данных. 5 минут звучат довольно хорошо для 8 миллионов count () из-за всех этих объединений.
вам нужно подумать о своей бизнес-проблеме и написать небольшой запрос / представление.
Несколько вещей, которые вы могли бы рассмотреть:
- денормализация. Уменьшите количество требуемых объединений за счет денормализации разделения структуры данных
- . Можете ли вы разделить данные из больших таблиц? например, большая таблица могла бы работать лучше, если бы была разделена на несколько меньших таблиц. Версия Enterprise Edition, начиная с SQL 2005, имеет хорошую поддержку разделения, см. здесь . Учли бы это, если бы вы начали попадать в области 10/100 миллионов строк
- управление индексами / статистика. Все индексы дефрагментированы? Актуальна ли статистика?
Запустите мастер настройки профилировщика / индекса sql. иногда он дает рекомендации по индексам, которые не сразу имеют смысл, но дают замечательные преимущества в производительности