Форум: "Прочее";
Текущий архив: 2013.03.31;
Скачать: [xml.tar.bz2];
Вниздольше ли будет запрос(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 не поможет.
← →
Inovet © (2012-12-05 11:42) [29]> [28] O"ShinW © (05.12.12 11:09)
> пример привел общего случая, где join не поможет.
А если саму с собой связать? Id и ParentId.
← →
наивный Талейран (2012-12-05 12:13) [30]
> Кука съела ник (04.12.12 20:56) [20]
>
> Любой запрос к объединению
там только синтаксически объединение
← →
Дмитрий С © (2012-12-05 12:26) [31]
> не знаю что под этим подразумевается
А в чем задача заключалась? Любопытно, что ты понимаешь под словосочетанием "транзитивное замыкание".
← →
O'ShinW © (2012-12-05 12:38) [32]
> А если саму с собой связать? Id и ParentId.
+
> А в чем задача заключалась? Любопытно, что ты понимаешь
> под словосочетанием "транзитивное замыкание".
Это была другая задача.
Не имеет отношения к вопросу.
словосочетание приведено (уже жалею, что приведено:)) для примера
зы
В той задаче (не имеющей отношения к теме) -, да, я там ввел Id и ParentId. Две таблицы, в mssql и в Oracle (копия из mssql)
В mssql писал функцию
в Oracle connect by prior
Потому что невозможно заранее предусмотреть кол-во join самой с собой
ps2
Я вот не пойму ,это троллинг пошел ?
← →
Inovet © (2012-12-05 12:49) [33]> [32] O"ShinW © (05.12.12 12:38)
> Я вот не пойму ,это троллинг пошел ?
Имхо, оффтоп.
← →
Аббат Пиккола (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]
> что при числе членов в несколько десятков тысяч текст может
> превысить допустимую длину (у меня такое случалось)
не иначе, диавол руку приложил
Если текст запроса генерируется автоматически то и с Божьей помощью он может вырасти до большой длины. :)
← →
O'ShinW © (2012-12-05 13:45) [38]
> не иначе, диавол руку приложил
не-не, бывает.
Может, как-то настраивается, но по дефолту, вроде 1 000.
зы
но не в этом случае,
тут перечисление не самих записей, а их групп
vs
предлагается выборку по общему слову в именах этих групп
← →
наивный Талейран (2012-12-05 13:46) [39]
> Если текст запроса генерируется автоматически
благими намерениями известно куда дорога выложена
← →
Аббат Пиккола (2012-12-05 13:49) [40]Допустим у меня есть сетка с множественным выбором. Пользователь может отметить строки, которые ему нравятся. Я просто фантазирую. И допустим я ничего не знаю о том, что текст SQL-запроса имеет реальные ограничения на длину. И вовсе не 4 гигабайт, как некоторые могут подумать. А гораздо меньше. И я, не долго думая, хочу запомнить отмеченные пользователем строки в виде перечисления их ID и применить в каком-то SQL-запросе. Ничего не зная о подобных ограничениях, так как о них мало где пишут. Пользователь же зачем-то решил для построения своего отчета (который он просил для "выбранных нескольких строк") отметить все записи в сетке, сняв все прочие фильтрации, а их там были десятки тысяч...
Ну например.
← →
наивный Талейран (2012-12-05 13:52) [41]
> Аббат Пиккола (05.12.12 13:49) [40]
> Пользователь же зачем-то решил ... отметить все записи в сетке, сняв все прочие фильтрации
голосую за возрождение святой инквизиции
← →
знайка (2012-12-05 13:56) [42]Надо пользоватся средствами сервера, раз ух заплатили за их, а не запросы генерить. :)
← →
Аббат Пиккола (2012-12-05 13:57) [43]2 наивный Талейран (05.12.12 13:52) [41]
На мой взгляд сжигать подозреваемых в колдовстве юзеров на кострах гуманнее, чем заранее отрубать им руки, как любят делать некоторые производители ПО.
:)
← →
наивный Талейран (2012-12-05 14:02) [44]
> Аббат Пиккола (05.12.12 13:57) [43]
поддерживаю
← →
MsGuns © (2012-12-05 14:12) [45]>знайка (05.12.12 13:56) [42]
>Надо пользоватся средствами сервера, раз ух заплатили за их, а не запросы >генерить. :)
Вот и я об этом же ([6]). Но ТС тот пост просто проигнорил :)
← →
O'ShinW © (2012-12-05 14:16) [46]
> MsGuns © (05.12.12 14:12) [45]
нет,
ТС читает все.
← →
Аббат Пиккола (2012-12-05 14:19) [47]Раз уж в MS SQL принято создавать временные таблицы, то действительно, почему бы ими не воспользоваться? Если у Вас MS SQL, конечно.
← →
MsGuns © (2012-12-05 14:21) [48]+
По сути топика вопрос. Откуда на клиенте берется 100500 значений, вставляемых в суперпупергиперзапрос ?
Есть три ответа:
1) Значения берутся из некоего набор данных, полученного на клиенте в результате выполнения опять же запроса.
Вопрос к разработчику: отчего не взять в качестве where/join on вот этот самый запрос, избежав опять же непонятных "ручных" суперзапросов ?
2) Значения вводятся непосредственно юзверем.
Вопрос к разработчику: каким образом юзверь сможет ввести 100500 значений ? А если их (значений) на три порядка меньше, то о чем тогда базар ?
3) Значения извлекаются из внешних источников (сторонние базы например).
Вопрос к разработчику: Почему не избрать путь промежуточной таблицы (6), ИМХО, наиболее оптимальный в данном случае ?
← →
Аббат Пиккола (2012-12-05 14:22) [49]В творчестве важно периодически преодолевать скорлупу собственных предубеждений. Иначе можно легко превратиться в старого брюзгу, который кроме фортрана ничего не вообще признает. А все остальное (что для сосунков) - его просто бесит!...
← →
MsGuns © (2012-12-05 14:22) [50]>Аббат Пиккола (05.12.12 14:19) [47]
Временные таблицы умеет создавать не только мс скл
← →
MsGuns © (2012-12-05 14:26) [51]Скажу больше - сейчас наверное не просто найти промсервер скл, не знающий временные таблицы
← →
Аббат Пиккола (2012-12-05 14:31) [52]2 MsGuns © (05.12.12 14:26) [51]
Я на InterBase вполне обхожусь без них.
Правда у меня много лет было одно преимущество - возможность порождать искусственные наборы с помощью ХП (оператор SUSPEND). Я слышал, что в последних версиях MS SQL тоже появилась такая возможность.
← →
Аббат Пиккола (2012-12-05 14:32) [53]А вообще это неважно. Хотелось бы услышать ответ на MsGuns © (05.12.12 14:21) [48]
← →
знайка (2012-12-05 14:34) [54]Да и не только временные таблицы, по месту надо смотреть что лучше, может юзердефайнтип, может xml может еще чего...
Вот запросы генерить это прошлый век.
← →
O'ShinW © (2012-12-05 14:35) [55]
> MsGuns © (05.12.12 14:21) [48]
вы таки будете смеяться, но запросу > 10 лет и его реально правили так, что добавляли новые id непосредственно в текст.
т.е. раньше там, я так подозреваю, было пару значений. Потом добавляли и добавляли. За десять лет имеем экран! айдишков в перечислении.
Мне "выпало счастье" его поправить в очередной раз.
Решил безобразие остановить.
Кстати, хотел создать таблицу, и даже не временную, а постоянную, и задокументировать ее добавление, как таблу под отчетность. С написанием интерфейса аля проект1.dpr, что бы манагеры сами решали какие группы туда добавить.
Но, имхо, красиво выходит, если искать лайком.
выдрал все id и запросил. В поле Name у всех есть слово "физические", точнее, "изически"
зы
Кстати, Серега, тебя я всегда внимательно читаю
← →
MsGuns © (2012-12-05 14:43) [56]>O"ShinW © (05.12.12 14:35) [55]
>За десять лет имеем экран! айдишков в перечислении.
Судя по этой фразе, надо срочно весь проект "в печку !" (с)
← →
Аббат Пиккола (2012-12-05 14:46) [57]В поле Name у всех есть слово "физические", точнее, "изически"
Это какое-то случайное совпадение?
Может быть лучше добавить колонку булевого типа, обозначающий "изичность" в ту таблицу, к которой собираетесь применять лайк? И однажды произвести там UPDATE с этим лайком? А в дальнейшем пусть манагеры, создавая там записи сами птичку ставят, в зависмости от того, "изический" у них объект там или не "изический". А то ведь "изический" с ошибкой ("изищеский") может как-нибудь сыграть злую шутку.
← →
MsGuns © (2012-12-05 14:47) [58]Удалено модератором
← →
O'ShinW © (2012-12-05 15:00) [59]
> Аббат Пиккола (05.12.12 14:46) [57]
может. Я уж думал.
Например, напишут в имени аля "только юридические, но не физические лица"
и в отчет попадет как "%изически%"
Но они только пишут служебки о добавлении, а уже добавляем мы, согласовывая м/д собой. На таком согласовании и выясняются необходимости правок.
> MsGuns © (05.12.12 14:47) [58]
Постепенно переводим, последние 2 года. На уракл, где совсем по-другому все будет. А пока приходится поддерживать недобитки.
Возможно, еще с год :)
← →
знайка (2012-12-05 15:02) [60]
> Но, имхо, красиво выходит, если искать лайком.
ну вот, а тут копья ломают :)
← →
Аббат Пиккола (2012-12-05 15:03) [61]2 MsGuns © (05.12.12 14:47) [58]
Я на днях видел фотку (знакомая зафиксировала распространенное явление в Непале). Когда у монахов и прочих местных жителей заканчиваются кизяки, на тот случай у них имеются солнечные батареи.
← →
Аббат Пиккола (2012-12-05 15:07) [62]Кто сказал, что солнечные батареи это повод сразу отказываться от кизяков? Я понимаю, что мы тут страна богатая... Ресурсами людскими и прочими. А вот бедные непальцы полагают иначе и экономят на всем.
← →
Дмитрий С © (2012-12-05 15:10) [63]Удалено модератором
← →
Кука съела ник (2012-12-05 15:42) [64]наивный Талейран (05.12.12 12:13) [30]
> там только синтаксически объединение
В одном случае обращение к одной таблице, в другом к двум.
Термин "синтаксически объединение" применительно к теории баз данных мне не знаком
← →
наивный Талейран (2012-12-05 16:01) [65]
> Кука съела ник (05.12.12 15:42) [64]
> В одном случае обращение к одной таблице, в другом к двум.
в выборке нет данных из второй таблицы и записей мало, плюс, планировщик(хочется надеяться) может как ему заблагорассудится преобразовать такой запрос
← →
Аббат Пиккола (2012-12-05 16:09) [66]Если так много сомнений, может вообще лучше ничего не трогать.
Я бы так долго не думал на эту тему, ей богу.
Значит там еще есть какой-то подводный камень...
Например, может быть очень хорошо для налогообложения, что какие-то ID находятся в специальном списке, который спрятан глубоко в недрах SQL-запросов.
А не в лежит у всех на виду в виде признака "Фирма-Поганка".
← →
Аббат Пиккола (2012-12-05 16:26) [67]Благими намерениями можно испортить многое. Приходит вот так программист. Нормальный вроде бы человек. Видит, ряд фирм "ООО Вася" через один пробел, а часть, например, "ООО Сигизмунд." - через два пробела. Да еще и с точкой в конце. И думает, а не отформатировать ли мне все эти фирмы так, чтобы было красиво...
А потом прибегает бухгалтер в ужасе "Что Вы наделали!!!!"...
Ситуация придуманная, но такое вполне возможно.
← →
Ваще имя (2012-12-05 16:35) [68]А меня раздражает нарицательный ID
← →
O'ShinW © (2012-12-05 16:40) [69]
> Аббат Пиккола (05.12.12 16:26) [67]
Возможно, конечно.
И примерно такое и бывало. Устаканилось уже.
Не, все равно надо как то менять. Такое перечисление ни к чему.
А когда запросил по id и по имени,
выяснилось, что некоторые группы, например, уже не актуальные.
т.е. ничего страшного, что они там есть, но могло бы их и не быть.
т.е. актуальные группы именуются по правилу,
остальные же просто пустые, или их листья мертвые.
Если продолжать добавлять группы по правилу - они автоматически будут попадать. т.е. запрос больше не надо переписывать.
Хотя.. по идее, можно еще одну группу ввести. (ну или таблицу эту)
← →
O'ShinW © (2012-12-05 16:43) [70]
> А меня раздражает нарицательный ID
чаще всего - меня тоже :)
Но если он например, ни к чему?
т.е. пусть таблица будет такая, где он не нужен.
Как истинный idот, я все равно введу его :)
Пусть будет. Сейчас не нужен, но неизвестно что потребуется завтра.
← →
Кука съела ник (2012-12-05 16:49) [71]наивный Талейран (05.12.12 16:01) [65]
> в выборке нет данных из второй таблицы и записей мало, плюс,
> планировщик(хочется надеяться) может как ему заблагорассудится
> преобразовать такой запрос
Для исполнения запроса в первом случае потребуется обращение к одной таблице, во втором случае к двум, неважно, есть в выборке или нет.
При прочих равных условиях обращение к двум таблицам всегда требует больше ресурсов, чем к одной.
← →
Ваще имя (2012-12-05 17:09) [72]
> пусть таблица будет такая, где он не нужен
> Сейчас не нужен, но неизвестно что потребуется завтра
Из этого следует, что синтетический ключ можно ввести завтра с тем же успехом
← →
Kerk © (2012-12-05 17:18) [73]
> Из этого следует, что синтетический ключ можно ввести завтра
> с тем же успехом
...и переписать все запросы.
← →
наивный Талейран (2012-12-05 17:31) [74]
> Кука съела ник (05.12.12 16:49) [71]
> При прочих равных условиях обращение к двум таблицам всегда
> требует больше ресурсов, чем к одной.
Во второй таблице 50 записей, ща проверим:
PointOfTruth:
if (TimeSelectFromTwoTable - TimeSelectFromOneTable) < 0.0000000000001 then
ShowMessage("Зануда")
else goto PointOfTruth;
← →
Ваще имя (2012-12-05 17:49) [75]
> goto
!!!
Страницы: 1 2 вся ветка
Форум: "Прочее";
Текущий архив: 2013.03.31;
Скачать: [xml.tar.bz2];
Память: 0.66 MB
Время: 0.006 c