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

[Vadik]

Цитата:

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

Вопрос не в том, какие варианты возможны?... как это лучше реализовать?... и т.п.
Вопрос в том, что быстрее exists join или like.

Кто сильнее - кит или слон?

Такая постановка вопроса не имеет смысла, так как единственный ответ на него - 'it depends'

Твой тест не на 100% корректен
Во-первых - не зря выше про выравнивание спросили. В зависимости от настроек выравнивания EDT выравнивания для LIKE могут различаться. Более адекватным для сравнения exists join с промежуточной таблицей был бы запрос (Trans.Id == 1 || Trans.Id == 2 || .. )
Во-вторых, начали c

SELECT LEDGERTRANS EXISTS JOIN

закончили

SELECT COUNT(RECID)

, у которого при наличии покрывающего индекса план выполнения будет значительно отличаться от исходного
и т.д.

У меня на LEDGERTRANS около 5 млн записей (правда, LEDGERTRANS индексирован нестандартно ) EXISTS JOIN с временной таблицей шуршит примерно на 60% (350мс против 600мс) быстрее

Все равно мне вариант с EXISTS JOIN не нравится - он будет сильно зависеть от условий запроса (наполнения промежуточной таблицы), т.е. менее предсказуем в дальнейшем. Если промежуточная таблица статичная (настроечная) - такой вариант имеет право на существование, если ее перед каждым запросом придется наполнять (не забываем про многопользовательскую работу) - отказать

[CDR]

Цитата:

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

Во-первых - не зря выше про выравнивание спросили.

Выравнивание - right, как и на большинстве основных справочников в системе.

Цитата:

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

Во-вторых, начали c

SELECT LEDGERTRANS EXISTS JOIN

закончили

SELECT COUNT(RECID)

, у которого при наличии покрывающего индекса план выполнения будет значительно отличаться от исходного

count(recId) был приделан для того, что бы оценить время выполнения запроса сиквелом полностью, т.к. вроде при обычном select'е выбирается только часть записей, определяемая всякими параметрами, кэшем и т.д. А в дальнейшем, при необходимости, довыбираются остальные.

Цитата:

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

Кто сильнее - кит или слон?

Такая постановка вопроса не имеет смысла, так как единственный ответ на него - 'it depends'
.........
Все равно мне вариант с EXISTS JOIN не нравится - он будет сильно зависеть от условий запроса (наполнения промежуточной таблицы), т.е. менее предсказуем в дальнейшем. Если промежуточная таблица статичная (настроечная) - такой вариант имеет право на существование, если ее перед каждым запросом придется наполнять (не забываем про многопользовательскую работу) - отказать

Позволю себе краткое резюме ...
Получается, что если 2-ая таблица (param), определяющая выборку записей из 1-ой (trans), - настроечная (является статической, и содержит не более 10-15 записей), то вариант с exists join значительно предпочтительнее использования like с маской, так как дает ощутимый прирост производительности (от в 1,5 до более чем в 10 раз).

[Alexius]

Цитата:

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

Выравнивание - right, как и на большинстве основных справочников в системе.

При выравнивании вправо like производит полное сканирование таблицы и выиграть у других вариантов у него нет шансов. Можете попробовать использовать вместо like условия >= <= , предложенные выше.

[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

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

Абсолютные величины времени исполнения какие? Если разница в 1...2 секунды, то это в пределах погрешности.

Еще попробуй EXISTS JOIN заменить на INNER JOIN

[CDR]

Цитата:

Сообщение от Владимир Максимов

Абсолютные величины времени исполнения какие? Если разница в 1...2 секунды, то это в пределах погрешности.

Еще попробуй EXISTS JOIN заменить на INNER JOIN

У меня на 200 000 записей время было около секунды, поэтому, собственно и пользовался функцией WinAPI::getTickCount() для большей точности вместо timeNow(). Сомнительно, что устойчивая разница в 10 раз является погрешностью. Меня больше интересует exists join, но как вариант, можно еще поиследовать и INNER JOIN

[Alexius]

Вопросы для тестового примера:
1. В какую сторону сделано выравнивание поля id ?
2. Какая версия SQL сервера ?
3. Какой Collation установлен на базе ?

[belugin]

а планы запросов можешь привести?

[belugin]

но тогда получается, что результат будет неэквивалентен like

[Alexius]

Цитата:

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

но тогда получается, что результат будет неэквивалентен like

В общем случае ДА, но для конкретного примера эквивалентен.