Вопрос знатокам сиквела

[CDR]

Всем превед!

Представим следующую ситуацию: есть табличка LedgerTrans с большим количеством записей (порядка 500 тыс.). Соответственно нужно выбрать из нее только записи, у которых счет равен 10.100 и 10.200. Внимание - вопрос!

Какой запрос отработает быстрее?
1. select LedgerTrans exist join param where LedgerTrans.AccountNum == param.AccountNum (param - табличка, в которой перечислены нужные счета, в нашем случае 10.100 и 10.200).
2. select LedgerTrans where LedgerTrans.AccountNum like "10.*"

[kashperuk]

А если взять да попробовать?

[belugin]

А так

select LedgerTrans where LedgerTrans.AccountNum >= "10."
&&
LedgerTrans.AccountNum <= "10.Я" // или LedgerTrans.AccountNum < "10<соедующий символ после точки>"

[CDR]

Цитата:

Сообщение от kashperuk

А если взять да попробовать?

Уже пробую .
Интересует просто механизмы этих двух конструкций и их соответственно теоритическое быстродействие

[egorych]

Если по AccountNum есть индекс, то с точки зрения SQL - like будет меньше ресурсов потреблять чем join. И потом exist join не факт что будет 1 запросом работать на сервере.

[Alexius]

Доп вопросы:
1. Какое число записей в LedgerTrans соответствуют условию ?
2. Какие индексы есть на таблице LedgerTrans ?
3. Таблица Param постоянная или временная ?
4. Какие индексы есть на таблице Param ?
5. Какое выравнивание у поля LedgerTrans.AccountNum, влево или вправо ?

[CDR]

Цитата:

Сообщение от egorych

Если по AccountNum есть индекс, то с точки зрения SQL - like будет меньше ресурсов потреблять чем join. И потом exist join не факт что будет 1 запросом работать на сервере.

Больше интересует скорость исполнения, а не потребляемые ресурсы. Что выполниться быстрее: построится join или просканируется like?

[Alexius]

Цитата:

Сообщение от CDR

Больше интересует скорость исполнения, а не потребляемые ресурсы. Что выполниться быстрее: построится join или просканируется like?

В большинстве случаев, чем меньше серверу потребуется ресурсов для выполнения запроса, тем быстрее он выполнится.

[tourist]

Цитата:

Сообщение от CDR

Всем превед!

Представим следующую ситуацию: есть табличка LedgerTrans с большим количеством записей (порядка 500 тыс.). Соответственно нужно выбрать из нее только записи, у которых счет равен 10.100 и 10.200. Внимание - вопрос!

Какой запрос отработает быстрее?
1. select LedgerTrans exist join param where LedgerTrans.AccountNum == param.AccountNum (param - табличка, в которой перечислены нужные счета, в нашем случае 10.100 и 10.200).
2. select LedgerTrans where LedgerTrans.AccountNum like "10.*"

Эти два запроса не эквивалентны, если нет уверенности, что все 10* счета записаны в табличку param и что так будет всегда.

[CDR]

Цитата:

Сообщение от tourist

Эти два запроса не эквивалентны, если нет уверенности, что все 10* счета записаны в табличку param и что так будет всегда.

Вопрос был не о эквивалентности двух запросов, а немного о другом

[belugin]

tourist, я полагаю теоретически вариант 2. быстрее, так как SQL в 1. варианте не знает, что можно обойтись index scan по AccountNum, и в 1 варианте сначала сделать tableScan по param, потом nestedLoop по всем записям и indexSсan по LedgerTranns

[CDR]

Хм... Только что опробовал обе конструкции на тестовой табличке с количеством записей около 200 тыс. Результат поразил, однако...
Конструкция с exist join выигрывает в скорости более чем в 10 раз

Ваши каменты по этому поводу?

[belugin]

А планчики можно?

А мой вариант?

[kashperuk]

Честно говоря, тоже думал, что второй будет работать быстрее.
Особенно учитывая, что у LedgerTrans есть индекс, где первым полем идет AccountNum.

Планы бы действительно интересно было посмотреть.

[Vadik]

Цитата:

Сообщение от CDR

Хм... Только что опробовал обе конструкции на тестовой табличке с количеством записей около 200 тыс. Результат поразил, однако...
Конструкция с exist join выигрывает в скорости более чем в 10 раз
Ваши каменты по этому поводу?

Предварительный диагноз - некорректный тест
Например, запрос в QA без фильтра на DataAreaId
ну и опять же метания между

Цитата:

в нашем случае 10.100 и 10.200)

и

Цитата:

where LedgerTrans.AccountNum like "10.*"

, что есть немного неравнозначные условия

покажи (ничего, что я на ТЫ? ) запросы и планы

[NNB]

Думаю, что Join быстрее при наличии индекса, так как с Like он не используется

[belugin]

select LedgerTrans where LedgerTrans.AccountNum >= "10."
&&
LedgerTrans.AccountNum < "10/"

[egorych]

Цитата:

Сообщение от NNB

Думаю, что Join быстрее при наличии индекса, так как с Like он не используется

если like '10%' то используется и очень даже эффективно!

[CDR]

Условия и план проведенного мной теста:

1. Создаем тестовую табличку Trans из двух полей: Id и Name.
2. На табличке создаем неуникальный индекс по полю Id, который делаем кластерным.
3. Создаем джобик, который в цикле наполняет эту таблицу значениями. У меня был такой: внешний цикл i от 1 до 40 000, внутренний цикл j от 1 до 12. Во внутреннем цикле вставляются записи в табличку из пункта 1 (Id = strfmt('%1',j)). Джобик рекомендуется запускать на довольно мощном серваке, а то уснуть можно
4. Создаем табличку Params с одним полем Id, На табличке создаем уникальный индекс, который делаем Primary и кластерным. В табличку вводим значения "1", "10", "11", "12".
5. Пишем тестовый джоб. В моем случае было два select'а:

select count(recId) from Trans
exists join Params
where Trans.Id == Params.Id;

select count(recId) from Trans
where Trans.Id like '1*';

Между select'ами смотрим время (я пользовался WinAPI::getTickCount() вместо timeNow(), дает более точное значение ).

6. Джобик запускаем пару раз, что б снизить влияние всякого там кэша. Затем можно поменять select'ы местами, для большей уверености

7. Результатами делимсо тут.

У меня, как я уже писал, exists join "сделал" like более чем в 10 раз

[CDR]

Цитата:

Сообщение от belugin

select LedgerTrans where LedgerTrans.AccountNum >= "10."
&&
LedgerTrans.AccountNum < "10/"

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

Вопрос в том, что быстрее exists join или like.