дольше ли будет запрос(MSSQL)?

← →
O'ShinW (2012-12-04 09:59) [0]

Есть таблица, SECOND (очень большая, тестовые прогоны не рекомендуются)
где есть столбец SECOND.FK_FIRST

Если писать запрос так
where
SECOND.ID in (1,2,3,4545,4546542,464346,634634,903867,145..)

или
добавить join FIRST on FIRST.ID = SECOND.FK_FIRST
where
FIRST.NAME like "%нечто общее%"

теоретически, намного дольше будет?
Просто меня бесит стиль "in (1,2,3,4545," - ничего не понятно.
а ".NAME like "%нечто общее%"" - очевидно сразу..

Однако, запрос нужно выполнить как можно быстрее
(ну, +- 5 минут, ерунда, т.к. более часа работает)

← →
sniknik © (2012-12-04 10:05) [1]

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

← →
Игорь Шевченко © (2012-12-04 10:06) [2]

> Просто меня бесит стиль

Выпей валерьянки и открой для себя EXPLAIN PLAN

← →
Ваще имя (2012-12-04 10:07) [3]

LIKE это очевидно сразу что full scan
Надо FIRST.NAME IN ("Вася Пупкин", "Петя Дупкин", ...) :-)

← →
O'ShinW (2012-12-04 10:32) [4]

> EXPLAIN PLAN

показывает примерно равные суммарные затраты

> например миллион может различаться на минуты.

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

зы
проверю
сегодня в ночь
сравню с предыдущими днями

← →
O'ShinW © (2012-12-04 10:41) [5]

Удалено модератором
Примечание: Флудить завязывай

← →
MsGuns © (2012-12-04 13:06) [6]

Подобные "вариантные" запросы предпочтительно реализовывать в два шага: а) создание временной таблицы и заполнение ее значениями образцов, б) выборка из основной таблицы с джоином ее с этой временной.

← →
sniknik © (2012-12-04 13:37) [7]

> ну, минуты - несущественно
т.е. пока до часу..nnn, не дорастет, т.е. пока "петух не клюнет" то "свои капризы ближе к телу"?

← →
наивный Талейран (2012-12-04 13:55) [8]

> O"ShinW (04.12.12 09:59)

> FIRST.NAME like

а сколько здесь записей?

← →
O'ShinW © (2012-12-04 14:01) [9]

> sniknik © (04.12.12 13:37) [7]

да, получается..
дорастет, посмотрим

Зато
1 следующий за мной будет разбирать, и сразу поймет, что выборка по XX
2 при новом XX не надо вспоминать про job
3 Пусть следующий почувствует себя умным, когда перечислит и отрапортует что ускорил :)

> > FIRST.NAME like
>
> а сколько здесь записей?

в пределах 50

← →
O'ShinW © (2012-12-04 14:14) [10]

> 1 следующий за мной будет разбирать, и сразу поймет, что
> выборка по XX

вообще-то, комментарий :)
ну да, или так

← →
O'ShinW © (2012-12-04 14:15) [11]

> 2 при новом XX не надо вспоминать про job

палка о двух концах, в общем случае..
но в моем, пожалуй, второй конец не страшен

← →
наивный Талейран (2012-12-04 16:33) [12]

> O"ShinW © (04.12.12 14:01) [9]
> в пределах 50

тогда я не вижу разницы между запросами

← →
O'ShinW © (2012-12-04 16:36) [13]

Сегодня посмотрим.
Так-то да, должно примерно одинаково быть.

← →
sniknik © (2012-12-04 16:42) [14]

> в пределах 50
50 это в чем ищут, или то, что запрос найдет?

← →
наивный Талейран (2012-12-04 16:46) [15]

> 50 это в чем ищут, или то, что запрос найдет?

это где ищут

> join FIRST on FIRST.ID = SECOND.FK_FIRST
> where
> FIRST.NAME like "%нечто общее%"

← →
sniknik © (2012-12-04 16:54) [16]

> это где ищут
тогда вообще в чем вопрос?
но вообще чего то так не кажется, судя по номерам id(автоинкремент?) в вопросе + [4] -
> ну да, я тоже думаю, что минуты
> и примерно так и есть, около миллиона записей

ИМХО, вы друг друга не поняли.

← →
наивный Талейран (2012-12-04 16:58) [17]

> sniknik © (04.12.12 16:54) [16]
>
> > это где ищут

дальше у меня было написано что ищут.

есть условие:
SECOND.ID in (1,2,3,4545,4546542,464346,634634,903867,145..)

и есть альтернативное:

> join FIRST on FIRST.ID = SECOND.FK_FIRST
> where
> FIRST.NAME like "%нечто общее%"

в FIRST - 50 записей.

← →
sniknik © (2012-12-04 17:03) [18]

в 50 записях пофигу как искать.

← →
O'ShinW © (2012-12-04 17:18) [19]

> в FIRST - 50 записей.

да

> в 50 записях пофигу как искать.

хорошо :)

← →
Кука съела ник (2012-12-04 20:56) [20]

Любой запрос к объединению по теории выполняется дольше, чем запрос к одной таблице при прочих равных.

← →
Аббат Пиккола (2012-12-04 22:49) [21]

А нет альтернативного такого пути:

where ... in (select ... from ... where ... like ...)

?

Некоррелированный подзапрос выполнится первым и единожды.

← →
O'ShinW © (2012-12-05 09:31) [22]

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

> Любой запрос к объединению по теории выполняется дольше

дык, почему и спросил :)

> where ... in (select ... from ... where ... like ...)

этот стиль тоже бесит :)

← →
Inovet © (2012-12-05 09:58) [23]

> [22] O"ShinW © (05.12.12 09:31)
> > where ... in (select ... from ... where ... like ...)
>
> этот стиль тоже бесит :)

Этот-то чем бесит?

← →
O'ShinW © (2012-12-05 10:02) [24]

> Этот-то чем бесит?

не укладыванием в принцип:
набор данных формируется соединениями во from
в where только фильтрация

понятно, что сложно так сделать, (бывает, что не возможно), но когда можно - надо делать так. Имхо.

← →
Дмитрий С © (2012-12-05 10:11) [25]

> бывает, что не возможно

Да ладно.

Все что можно сделать с помощью where ... in (select ... from ... where ... like ...) можно сделать с помощью join-ов.

Как по мне - чем больше ты оставишь пространства MSSQL для оптимизации - тем скорее он выполнит запрос.

Но я думаю что и без того твой запрос можно ускорить, избежав LIKE "%

← →
O'ShinW © (2012-12-05 10:39) [26]

> Все что можно сделать с помощью where ... in (select ...
> from ... where ... like ...) можно сделать с помощью join-
> ов.

а кто спорил?

фраза
> бывает, что не возможно
относится к общему случаю.
Например ,к транзитивному замыканию, которое не реализуется через join

← →
Дмитрий С © (2012-12-05 10:51) [27]

> Например ,к транзитивному замыканию, которое не реализуется
> через join

Почему так категорично? Например, в дереве реализуется. Только причем там join?

← →
O'ShinW © (2012-12-05 11:09) [28]

> Дмитрий С © (05.12.12 10:51) [27]

не знаю что под этим подразумевается, я через connect ..prior в oracle делал. В mssql писал функцию.

> Только причем там join?

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

> [28] O"ShinW © (05.12.12 11:09)
> пример привел общего случая, где join не поможет.

А если саму с собой связать? Id и ParentId.

← →
наивный Талейран (2012-12-05 12:13) [30]

> Кука съела ник (04.12.12 20:56) [20]
>
> Любой запрос к объединению

там только синтаксически объединение

> не знаю что под этим подразумевается

А в чем задача заключалась? Любопытно, что ты понимаешь под словосочетанием "транзитивное замыкание".

> А если саму с собой связать? Id и ParentId.

+

> А в чем задача заключалась? Любопытно, что ты понимаешь
> под словосочетанием "транзитивное замыкание".

Это была другая задача.
Не имеет отношения к вопросу.
словосочетание приведено (уже жалею, что приведено:)) для примера

зы
В той задаче (не имеющей отношения к теме) -, да, я там ввел Id и ParentId. Две таблицы, в mssql и в Oracle (копия из mssql)
В mssql писал функцию
в Oracle connect by prior
Потому что невозможно заранее предусмотреть кол-во join самой с собой

ps2
Я вот не пойму ,это троллинг пошел ?

← →
Аббат Пиккола (2012-12-05 13:31) [34]

O"ShinW © (05.12.12 10:02) [24]

набор данных формируется соединениями во from
в where только фильтрация

Мне кажется, это какое-то вредное предубеждение. Приобретая сервер, Вы приобретаете в том числе и функциональность, допускающую обработку подзапросов. Если Вы принципиално не желаете ею пользоваться, значит Вы переплатили за сервер.

По мне так любой запрос (с самым дебильным текстом), работающий хотя бы на 10% быстрее прочих, уже рассматривается как возможно наилучший. Разумеется, запрос, содержащий явное перечисление в IN (111,1212,1231,...) просто опасен. Но не дебильностью текста (текст - очевидно дебильный, если в перечислении куча членов), а тем, что при числе членов в несколько десятков тысяч текст может превысить допустимую длину (у меня такое случалось) и запрос просто провалится.

Что же касается "бесит"... Все зависит от степени эгоизма повара.
Допустим я пришел в кафе. И заказал кофе эспрессо (по-быстрому -очень спешу). Вряд ли я буду в восторге, если официант заставит меня ждать лишних 5 минут только потому что повара "бесит" подавать кофе в неподогретой по всем правилам чашке.

← →
наивный Талейран (2012-12-05 13:36) [35]

> что при числе членов в несколько десятков тысяч текст может
> превысить допустимую длину (у меня такое случалось)

не иначе, диавол руку приложил

← →
знайка (2012-12-05 13:40) [36]

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

← →
Аббат Пиккола (2012-12-05 13:42) [37]

наивный Талейран (05.12.12 13:36) [35]

> что при числе членов в несколько десятков тысяч текст может
> превысить допустимую длину (у меня такое случалось)

не иначе, диавол руку приложил

Если текст запроса генерируется автоматически то и с Божьей помощью он может вырасти до большой длины. :)

> не иначе, диавол руку приложил

не-не, бывает.
Может, как-то настраивается, но по дефолту, вроде 1 000.

зы
но не в этом случае,
тут перечисление не самих записей, а их групп
vs
предлагается выборку по общему слову в именах этих групп

← →
наивный Талейран (2012-12-05 13:46) [39]

> Если текст запроса генерируется автоматически

благими намерениями известно куда дорога выложена

← →
Аббат Пиккола (2012-12-05 13:49) [40]

Допустим у меня есть сетка с множественным выбором. Пользователь может отметить строки, которые ему нравятся. Я просто фантазирую. И допустим я ничего не знаю о том, что текст SQL-запроса имеет реальные ограничения на длину. И вовсе не 4 гигабайт, как некоторые могут подумать. А гораздо меньше. И я, не долго думая, хочу запомнить отмеченные пользователем строки в виде перечисления их ID и применить в каком-то SQL-запросе. Ничего не зная о подобных ограничениях, так как о них мало где пишут. Пользователь же зачем-то решил для построения своего отчета (который он просил для "выбранных нескольких строк") отметить все записи в сетке, сняв все прочие фильтрации, а их там были десятки тысяч...

Ну например.

дольше ли будет запрос(MSSQL)? Найти похожие ветки