Sql #table vs Присоединиться к Join, что лучше в производительности [дубликат]

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

5
задан Nate Barbettini 1 October 2015 в 05:14
поделиться

3 ответа

Очевидно, что SQL Server выбирает неправильный план запроса. Да, это может произойти, у меня был точно такой же сценарий, как и вы несколько раз.

Проблема в том, что оптимизация запроса (вы называете «сложный подзапрос») - нетривиальная задача: Если у вас есть n таблиц, есть примерно n! возможно присоединиться заказы - и это только начало. Итак, вполне правдоподобно, что (а) сначала ваш внутренний запрос и (б), то ваш внешний запрос - хороший способ, но SQL Server не может вывести эту информацию в разумные сроки.

Что вы можете do - help SQL Server. Как пишет Dan Tow в своей большой книге « SQL Tuning », ключ, как правило, является порядком соединения, переходящим от наиболее избирательной к минимально избирательной таблице. Используя здравый смысл (или метод, описанный в его книге, что намного лучше), вы можете определить, какой порядок соединения будет наиболее уместным, а затем использовать подсказку FORCE ORDER .

В любом случае, каждый запрос уникален, нет «волшебной кнопки», чтобы ускорить работу SQL Server. Если вы действительно хотите узнать, что происходит, вам нужно посмотреть (или показать нам) планы запросов ваших запросов. Другие интересные данные показаны SET STATISTICS IO , которые расскажут вам, сколько (дорогого) доступа к жесткому диску вы получаете.

3
ответ дан Heinzi 22 August 2018 в 22:55
поделиться

Я повторил этот вопрос здесь: Как принудительно выполнить подзапрос, а также таблицу #temp?

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

0
ответ дан Community 22 August 2018 в 22:55
поделиться
  • 1
    Просто обновить. Мартин Смит дал ответ, который работал для меня, указав здесь: connect.microsoft.com/SQLServer/feedback/details/218968 Вероятно, это устранило проблему этого айзера, хотя Мартин указал, что катушка не " t имеют статистику, подобную темпам таблицы, и это хак, который требует ORDER BY, который может понести реальную стоимость для некоторых. – Adamantish 12 September 2013 в 16:19

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

Конечно, я также видел, что временные таблицы замедляют работу, иногда намного медленнее.

Там не является заменой для профилирования и изучения планов запросов (однако, с их оценкой с зерном соли).

4
ответ дан Marcelo Cantos 22 August 2018 в 22:55
поделиться
Другие вопросы по тегам:

Похожие вопросы: