В каких случаях INNER JOIN (SELECT) нельзя перезаписывать с использованием временной таблицы

Я использую GridSQL, где у меня возникают некоторые проблемы с производительностью всякий раз, когда возникает шаблон SQL INNER JOIN (SELECT). Поэтому я рассматриваю возможность переписать все эти запросы в два запроса, один из которых создает временную таблицу с использованием оператора точного выбора, а другой запрос объединяется с временным table, поэтому вместо этого шаблон будет INNER JOIN temp_table (...).

В каких случаях это не сработает? Как вы, наверное, подозреваете, я не надеюсь получить ответы на этот вопрос. ;)


postgresql sql join subquery
person David    schedule 18.09.2009    source источник

Ответы (3)


arrow_upward
1
arrow_downward

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

Для "... INNER JOIN (SELECT..." я сомневаюсь, что у вас возникнет эта проблема (или, если это вообще возможно, я не помню, чтобы когда-либо пытался это сделать), поскольку вы должны ссылаться только на поля из первой таблицы в критерии соединения.

person Timothy Walters    schedule 18.09.2009

arrow_upward
1
arrow_downward

Я не думаю, что временная таблица ускорит ваши запросы! Вместо этого вы должны оптимизировать свои запросы. Что вы можете сделать:

  • Отфильтруйте записи перед их внутренним соединением с другими наборами записей.
  • Определите правильные индексы

-Павел

person Pavel Nikolov    schedule 18.09.2009
comment
Возможно, оптимизатор запросов для SQL выполняет шаги, которые вы хотите выполнить вручную, поэтому вы не увидите ускорения. - person mmmmmm; 18.09.2009
comment
Оптимизатор запросов делает за вас много работы, но я уверен, что он не может оптимизировать каждый запрос... И считается хорошей идеей фильтровать все наборы перед их объединением вместо того, чтобы сначала объединять большое количество записей, а затем фильтровать. их! Более того, оптимизатор запросов SQL не будет создавать для вас индексы! - person Pavel Nikolov; 18.09.2009
comment
Я согласен с вами, если вы говорите о MySQL, PostgreSQL или чем-то подобном, хотя GridSQL — это особый случай, когда у вас есть несколько узлов, а планировщик запросов не такой зрелый, как для двух упомянутых. Я знаю, как это влияет на производительность (от 10-20 минут на запрос до менее тридцати секунд). - person David; 18.09.2009

arrow_upward
0
arrow_downward

В каких случаях INNER JOIN (SELECT … не может быть переписан с использованием временной таблицы)

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

person KM.    schedule 18.09.2009