Настройка SQL - с несколькими объединениями

Question

Недавно я где-то читал, что один из способов настройки SQL-запроса состоит в том, что, если у него слишком много объединений, то нужно выполнить одно объединение с меньшим количеством таблиц и кэшировать результаты во временную таблицу, а затем выполнить оставшуюся часть запроса, объединяющуюся с этим стол.

У меня вопрос, как это улучшит производительность, поскольку вы объединяете одинаковое количество таблиц (только не вместе)?

Примечание: я согласен, что это общее утверждение; Я прочитал это недавно в какой-то статье. Я перефразирую это. При каких условиях поможет сохранение результата во временной таблице?

Answer 1

Одна из причин, по которой вы инвестируете в такой продукт, как Oracle, заключается в разработке, которую они вложили в оптимизатор своего движка. За 20 с лишним лет он постоянно улучшался, и в целом при наличии надлежащей статистики для ваших таблиц и индексов трудно правильно переоценить ее для доступа к вашим данным.

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

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

Answer 2

Это очень сильно зависит от вашей конкретной ситуации - такие изменения могут повредить или улучшить производительность.Там нет общего правила для этого;с каким запросом у вас возникают проблемы?

Это может повысить производительность, поскольку в результате может появиться таблица меньшего размера, к которой проще обращаться и присоединяться;Оптимизатор запросов может сделать это автоматически, но в некоторых случаях ошибается.Это способ выполнения работы оптимизатора вручную.

Answer 3

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

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

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

Answer 4

Я бы никогда не подумал об использовании временных таблиц для повышения производительности одного запроса. (Я предполагаю, что вы говорите о реальных таблицах, а не о материализованных представлениях.) По моему опыту, Oracle может без проблем объединять несколько десятков таблиц, по крайней мере, в 99,9% случаев. (Если у вас есть актуальная статистика.)

В тех редких случаях, когда вещи кажутся неоптимальными, вам следует сначала попробовать поработать в системе, которую предоставляет вам Oracle. Большинство проблем с производительностью, которые я вижу, заключаются в том, что кто-то не делает что-то логически или не знает о существующих функциях. Например, используя одну и ту же таблицу дважды вместо использования аналитики. Если Oracle по-прежнему использует неверный план объяснения, вам следует использовать подсказки или хитрость, например, добавить ROWNUM, чтобы не дать Oracle переписать определенные подзапросы.

Если временная таблица поможет, Oracle сделает все за вас. Иногда в плане объяснения можно увидеть объекты типа «SYS_TEMP ...».

Answer 5

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

ТеоретическиМожно точно проследить, как оптимизатор Oracle принимает свое решение, и использовать статистику, подсказки и планы, чтобы предоставить ему информацию, необходимую для правильной работы.

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

Недостаток времениТабличный подход заключается в том, что вы предотвратили использование «лучшей» оптимизации базы данных при изменении ресурсов (т. е. сервер БД теперь имеет 8 ГБ памяти, поэтому самый быстрый подход заключается в загрузке всех таблиц целиком в память, но метод временных таблиц имеетпринудительная запись обратно на диск).