sql tuning - с несколькими объединениями

Question

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

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

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

Answer 1

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

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

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

Answer 2

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

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

В качестве альтернативы, многие базы данных поддерживают материализованные представления (или индексированные представления), которые являются фактически временными таблицами, которые обновляются автоматически при каждом обновлении.

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

Answer 3

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

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

Answer 4

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

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

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

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

Answer 5

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

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

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