SQLRU.net
Разработка приложений баз данных

Начало » Использование СУБД » Firebird, HQbird, InterBase » Изменения оптимизатора?
Изменения оптимизатора? [сообщение #140] Tue, 05 July 2022 19:55 Переход к следующему сообщению
optimiz94 в настоящее время не в онлайне  optimiz94
Сообщений: 15
Зарегистрирован: July 2022
Junior Member
Есть такой запрос:

select m.Id
from Items_Main m
left join Items_Ext e on e.Id=m.Id
where m.f0=?p0
and e.f1=?p1
and e.f2=?p2
and e.f3=?p3
and e.f4=?p4
На все поля, перечисленные в where, есть индексы (точнее, foreign keys, а индексы уже следствие).

Раньше FB использовал индекс по m.f0, и не мог использовать индексы по таблице e, потому что она была в left join. Теперь может, и это ломает планы. По полям f0 и f1 хорошая селективность, но оптимизатор использует не просто индекс по f1, а пересечение индексов по f1 и f2. Пересечение индексов наверное хорошая вешь для аналитических запросов, но для быстрых OLTP это просто беда, нужно всегда следить, чтобы такого не случилось.
В моём случае нужно переписать запрос как
where m.f0=?p0 and e.f1=?p1 and e.f2+0=?p2 and e.f3+0=?p3 and e.f4+0=?p4
Я думал, что это хорошая идея делать left join, чтобы исключить использование индексов (этот же трюк и в SQL Server работает). Теперь придётся видимо так делать:
left join Items_Ext e on e.Id=m.Id+0
Изменение произошло где-то между WI-V3.0.8.33392 и WI-V3.0.8.33540.
Это значит, при переезде с FB3 на FB4 может много чего полететь.
Re: Изменения оптимизатора? [сообщение #141 является ответом на сообщение #140] Tue, 05 July 2022 20:25 Переход к предыдущему сообщениюПереход к следующему сообщению
BlackEric в настоящее время не в онлайне  BlackEric
Сообщений: 369
Зарегистрирован: June 2022
Senior Member
Чем мешает использование индексов?
Сильно проседает скорость?
Насколько?
Re: Изменения оптимизатора? [сообщение #142 является ответом на сообщение #141] Tue, 05 July 2022 20:40 Переход к предыдущему сообщениюПереход к следующему сообщению
optimiz94 в настоящее время не в онлайне  optimiz94
Сообщений: 15
Зарегистрирован: July 2022
Junior Member
Пересечение индексов очень медленная операция.
Она оправдана, когда запрос возвращает миллионы строк.
Если запрос возвращает 1-2 строки, а нужно прочитать целиком пару индексов в огромных таблицах, это плюс 2-5 секунд к выполнению (против сотен миллисекунд при использовании одного индекса). Под нагрузкой супер-критично.

Впрочем, я проверил на более свежей версии WI-V3.0.10.33587 - вернули старое поведение.
Это был баг?

[Обновления: Tue, 05 July 2022 20:41]

Известить модератора

Re: Изменения оптимизатора? [сообщение #148 является ответом на сообщение #142] Thu, 07 July 2022 08:07 Переход к предыдущему сообщениюПереход к следующему сообщению
m7m в настоящее время не в онлайне  m7m
Сообщений: 18
Зарегистрирован: June 2022
Географическое положение: Мариуполь,Укр...
Junior Member
>>Раньше FB использовал индекс по m.f0, и не мог использовать индексы по таблице e
Это неверное утверждение/вывод, ну по крайней мере вторая часть "не мог использовать индексы по таблице e"

>>Это был баг?
Скорее изменилась селективность индексов
Re: Изменения оптимизатора? [сообщение #151 является ответом на сообщение #148] Thu, 07 July 2022 15:00 Переход к предыдущему сообщениюПереход к следующему сообщению
optimiz94 в настоящее время не в онлайне  optimiz94
Сообщений: 15
Зарегистрирован: July 2022
Junior Member
m7m писал(а) Thu, 07 July 2022 08:07
Это неверное утверждение/вывод, ну по крайней мере вторая часть "не мог использовать индексы по таблице e"
Ну я всегда использовал left join как hint оптимизатору "не использовать индексы на этой таблице" (кроме индекса по полю join, разумеется).

Можете на своих базах воспроизвести пример, когда индекс применяется в этом случае?

Вот мой пример: две огромные таблицы Items_Main и Items_Ext, параллельно связаны по полю Id.
В запросе
select m.Id
from Items_Main m
left join Items_Ext e on e.Id=m.Id
where e.f1=?p1
Используется ужасно медленный план с полным сканом первой таблицы, хотя по индексу на второй таблице моментально выбралась бы ровно одна запись
PLAN JOIN (M NATURAL, E INDEX (PK_ITEMS_EXT))

[Обновления: Thu, 07 July 2022 15:02]

Известить модератора

Re: Изменения оптимизатора? [сообщение #152 является ответом на сообщение #151] Fri, 08 July 2022 09:35 Переход к предыдущему сообщениюПереход к следующему сообщению
m7m в настоящее время не в онлайне  m7m
Сообщений: 18
Зарегистрирован: June 2022
Географическое положение: Мариуполь,Укр...
Junior Member
>>Ну я всегда использовал left join как hint оптимизатору "не использовать индексы на этой таблице" (кроме индекса по полю join, разумеется).
>>Можете на своих базах воспроизвести пример, когда индекс применяется в этом случае?
Не могу, ибо именно про индексы по join я и имел ввиду
---------------

Блин я тебя не понимаю, откуда для запроса
select m.Id
from Items_Main m
left join Items_Ext e on e.Id=m.Id
where e.f1=?p1
может появиться план
PLAN JOIN (M INDEX (.....), E INDEX (PK_ITEMS_EXT))
ты ж не накладываешь никаких ограничений на Items_Main m

Более того этот запрос, в данном случае эквивалентен запросу
select m.Id
from Items_Main m
join Items_Ext e on e.Id=m.Id
where e.f1=?p1
который будет наверное эффективней чем исходный
и план наверное будет где-то такой
PLAN JOIN (E INDEX (.....), M  INDEX (.....))
или я вообще не понимаю, о чем речь

Re: Изменения оптимизатора? [сообщение #156 является ответом на сообщение #152] Fri, 08 July 2022 19:04 Переход к предыдущему сообщениюПереход к следующему сообщению
optimiz94 в настоящее время не в онлайне  optimiz94
Сообщений: 15
Зарегистрирован: July 2022
Junior Member
В WI-V3.0.8.33540 для запроса
select m.Id
from Items_Main m
left join Items_Ext e on e.Id=m.Id
where m.f0=?p0
and e.f1=?p1
and e.f2=?p2
and e.f3=?p3
and e.f4=?p4
появился план примерно такой (пишу по памяти, версию уже обновили и доступа у меня к ней нет. могу где-то опечататься, но в целом так)
PLAN JOIN (E INDEX (FK_ITEMS_EXT_REF_F1, FK_ITEMS_EXT_REF_F2), M INDEX (PK_ITEMS_MAIN))
и это стало большой проблемой.

То есть, сервер никогда не использовал индексы по таблице, подключенной через left join, и вдруг начал.

[Обновления: Fri, 08 July 2022 19:16]

Известить модератора

Re: Изменения оптимизатора? [сообщение #157 является ответом на сообщение #152] Fri, 08 July 2022 19:11 Переход к предыдущему сообщениюПереход к следующему сообщению
optimiz94 в настоящее время не в онлайне  optimiz94
Сообщений: 15
Зарегистрирован: July 2022
Junior Member
m7m писал(а) Fri, 08 July 2022 09:35

Более того этот запрос, в данном случае эквивалентен запросу ... который будет наверное эффективней чем исходный
и план наверное будет где-то такой
PLAN JOIN (E INDEX (.....), M  INDEX (.....))
Да, эквивалентен, но оптимизатор не умеет его делать если таблица, по которой хороший индекс, приджойнена через left join.
Если считаете, что умеет, покажите тестовый скрипт (создать пару табличек, накидать пару тысяч записей и посмотреть план запроса) - у меня такое не выходит.

Если left join заменить на inner join - тогда да, оптимизатор начинает использовать хороший индекс по E.
Re: Изменения оптимизатора? [сообщение #158 является ответом на сообщение #156] Fri, 08 July 2022 22:31 Переход к предыдущему сообщениюПереход к следующему сообщению
m7m в настоящее время не в онлайне  m7m
Сообщений: 18
Зарегистрирован: June 2022
Географическое положение: Мариуполь,Укр...
Junior Member
optimiz94 писал(а) Fri, 08 July 2022 19:04
В WI-V3.0.8.33540 для запроса
select m.Id
from Items_Main m
left join Items_Ext e on e.Id=m.Id
where m.f0=?p0
and e.f1=?p1
and e.f2=?p2
and e.f3=?p3
and e.f4=?p4
появился план примерно такой (пишу по памяти, версию уже обновили и доступа у меня к ней нет. могу где-то опечататься, но в целом так)
PLAN JOIN (E INDEX (FK_ITEMS_EXT_REF_F1, FK_ITEMS_EXT_REF_F2), M INDEX (PK_ITEMS_MAIN))
и это стало большой проблемой.

То есть, сервер никогда не использовал индексы по таблице, подключенной через left join, и вдруг начал.
Для этого запроса план более чем странный Sad

Re: Изменения оптимизатора? [сообщение #159 является ответом на сообщение #157] Fri, 08 July 2022 22:43 Переход к предыдущему сообщениюПереход к следующему сообщению
m7m в настоящее время не в онлайне  m7m
Сообщений: 18
Зарегистрирован: June 2022
Географическое положение: Мариуполь,Укр...
Junior Member
optimiz94 писал(а) Fri, 08 July 2022 19:11
m7m писал(а) Fri, 08 July 2022 09:35

Более того этот запрос, в данном случае эквивалентен запросу ... который будет наверное эффективней чем исходный
и план наверное будет где-то такой
PLAN JOIN (E INDEX (.....), M  INDEX (.....))
Да, эквивалентен, но оптимизатор не умеет его делать если таблица, по которой хороший индекс, приджойнена через left join.
Если считаете, что умеет, покажите тестовый скрипт (создать пару табличек, накидать пару тысяч записей и посмотреть план запроса) - у меня такое не выходит.

Если left join заменить на inner join - тогда да, оптимизатор начинает использовать хороший индекс по E.
Судя по тексту запроса
select m.Id
from Items_Main m
left join Items_Ext e on e.Id=m.Id
where m.f0=?p0
and e.f1=?p1
and e.f2=?p2
and e.f3=?p3
and e.f4=?p4
тебе left join совершенно не нужен, и пожалуй даже вреден
и я не понимаю упорного желания его использовать ибо он по результатам совершенно эквивалентен запросу
select m.Id
from Items_Main m
join Items_Ext e on e.Id=m.Id
where m.f0=?p0
and e.f1=?p1
and e.f2=?p2
and e.f3=?p3
and e.f4=?p4
который дает волю оптимизатору построить оптимальный с его точки зрения план
И при этом если по каким-то причинам надо ограничить его свободу в использовании индексов
то заставить оптимизатор не использовать индекс можно как-то так e.f1+0=?p1
Re: Изменения оптимизатора? [сообщение #160 является ответом на сообщение #159] Sat, 09 July 2022 01:20 Переход к предыдущему сообщениюПереход к следующему сообщению
optimiz94 в настоящее время не в онлайне  optimiz94
Сообщений: 15
Зарегистрирован: July 2022
Junior Member
m7m, я не прошу помочь с написанием запроса.
Я здесь, чтобы обсудить факт - поведение оптимизатора существенно менялось, и возможно разработчики СУБД что-то скажут по этому поводу: это временный сбой был, или в будущих версиях они введут эту (в принципе, корректную) оптимизацию, и надо это иметь ввиду.

Также я зацепился за утверждение:
m7m писал(а) Thu, 07 July 2022 08:07
>>Раньше FB использовал индекс по m.f0, и не мог использовать индексы по таблице e
Это неверное утверждение/вывод, ну по крайней мере вторая часть "не мог использовать индексы по таблице e"
Если у вас такое на практике встречалось, прошу посмотреть - повторяется ли оно сейчас. Но я уже понимаю, что вы похоже просто теоретизировали.
Re: Изменения оптимизатора? [сообщение #161 является ответом на сообщение #160] Sat, 09 July 2022 07:22 Переход к предыдущему сообщениюПереход к следующему сообщению
m7m в настоящее время не в онлайне  m7m
Сообщений: 18
Зарегистрирован: June 2022
Географическое положение: Мариуполь,Укр...
Junior Member
optimiz94 писал(а) Sat, 09 July 2022 01:20

Также я зацепился за утверждение:
m7m писал(а) Thu, 07 July 2022 08:07
>>Раньше FB использовал индекс по m.f0, и не мог использовать индексы по таблице e
Это неверное утверждение/вывод, ну по крайней мере вторая часть "не мог использовать индексы по таблице e"
Если у вас такое на практике встречалось, прошу посмотреть - повторяется ли оно сейчас. Но я уже понимаю, что вы похоже просто теоретизировали.
Я уже ответил на это:
>>Ну я всегда использовал left join как hint оптимизатору "не использовать индексы на этой таблице" (кроме индекса по полю join, разумеется).
>>Можете на своих базах воспроизвести пример, когда индекс применяется в этом случае?
Не могу, ибо именно про индексы по join я и имел ввиду

И таки да я теоретизировал, и продолжаю это делать

[Обновления: Sat, 09 July 2022 07:44]

Известить модератора

Re: Изменения оптимизатора? [сообщение #162 является ответом на сообщение #160] Sat, 09 July 2022 07:38 Переход к предыдущему сообщениюПереход к следующему сообщению
m7m в настоящее время не в онлайне  m7m
Сообщений: 18
Зарегистрирован: June 2022
Географическое положение: Мариуполь,Укр...
Junior Member
optimiz94 писал(а) Sat, 09 July 2022 01:20
m7m, я не прошу помочь с написанием запроса.
Я здесь, чтобы обсудить факт - поведение оптимизатора существенно менялось, и возможно разработчики СУБД что-то скажут по этому поводу: это временный сбой был, или в будущих версиях они введут эту (в принципе, корректную) оптимизацию, и надо это иметь ввиду.
Да я и не помогаю, я для себя пытаюсь понять задлянафига такое делать.

select m.Id
from Items_Main m
left join Items_Ext e on e.Id=m.Id
where m.f0=?p0
and e.f1=?p1
and e.f2=?p2
and e.f3=?p3
and e.f4=?p4

Сочетание left join и условие в where на ведомую таблицу в моей голове не укладывается
Re: Изменения оптимизатора? [сообщение #163 является ответом на сообщение #162] Sat, 09 July 2022 11:37 Переход к предыдущему сообщениюПереход к следующему сообщению
optimiz94 в настоящее время не в онлайне  optimiz94
Сообщений: 15
Зарегистрирован: July 2022
Junior Member
m7m писал(а) Sat, 09 July 2022 07:38
Да я и не помогаю, я для себя пытаюсь понять задлянафига такое делать.
Сочетание left join и условие в where на ведомую таблицу в моей голове не укладывается
select m.Id
from Items_Main m
left join Items_Ext e on e.Id=m.Id
where m.f0=?p0
and e.f1=?p1
and e.f2=?p2
and e.f3=?p3
and e.f4=?p4
В этой схеме данных такая специфика, что по полю f0 очень высокая селективность, во всей таблице M для любого значения выберется в пределах 10 строк (F0 это номер заказа), а по полям F1-F4 так себе селективность (это номенклатура). Поэтому я поставил left join, чтобы оптимизатор никогда не использовал индексы по E.

А тот запрос, который вызвал ваше недоумение
select m.Id
from Items_Main m
left join Items_Ext e on e.Id=m.Id
where e.f1=?p1
это попытка в чистом виде выделить проблему.

[Обновления: Sat, 09 July 2022 11:46]

Известить модератора

Re: Изменения оптимизатора? [сообщение #166 является ответом на сообщение #163] Mon, 11 July 2022 15:34 Переход к предыдущему сообщениюПереход к следующему сообщению
sim_84 в настоящее время не в онлайне  sim_84
Сообщений: 332
Зарегистрирован: June 2022
Senior Member
1. Оптимизатор всегда мог использовать индексы полей в условии соединения left join. Он не мог и не может прокидывать условие из where к правой таблице.
Кстати есть наработки которые превращают такие left в inner join.

2. Использовать left join как подсказку есть глупость. Подсказки это +0 и || и то до тех пор пока нативных нет.

И да "left join e ... where e. ..." вызывает недоумение
Re: Изменения оптимизатора? [сообщение #182 является ответом на сообщение #166] Thu, 14 July 2022 11:17 Переход к предыдущему сообщениюПереход к следующему сообщению
optimiz94 в настоящее время не в онлайне  optimiz94
Сообщений: 15
Зарегистрирован: July 2022
Junior Member
Спасибо за ответ.

>> 1. Оптимизатор всегда мог использовать индексы полей в условии соединения left join

Я понимаю, что в операторе
left join e on e.Id = m.Id
используется индекс по e.Id

Вопрос этого топика в том, может ли в конструкции
left join e on e.Id = m.Id
where e.f1 = ?f1
использоваться индекс по e.f1
У меня ни на каких версиях не получалось
Кроме одной странной, с которой я начал топик - изменения в ней настораживают.


>> 2. Использовать left join как подсказку есть глупость

Понятно, но раньше отключение индексов хинтом 'left join' всегда работало.
Буду потихоньку переписывать на +0

>> Кстати есть наработки которые превращают такие left в inner join.

Видимо, я на такую наработку и нарвался.
Такое надо осторожно менять, потому что может много систем сломать в проде.


Кстати, есть ещё досадный баг с left join. В запросе
select *
from Items_Main m
join Items_Ext e on e.Id=m.Id
where e.F1 = ?f1
работает индекс по e.F1

А в запросе
select *
from Items_Main m
left join Users u on u.UserId=m.UserId
join Items_Ext e on e.Id=m.Id
where e.F1 = ?f1
индекс уже не работает, план
PLAN JOIN (JOIN (M NATURAL, U INDEX (PK_USERS)), E INDEX (PK_ITEMS_EXT))

А вот так - все в порядке

select *
from Items_Main m
join Items_Ext e on e.Id=m.Id
left join Users u on u.UserId=m.UserId
where e.F1 = ?f1
PLAN JOIN (JOIN (E INDEX (FK_ITEMS_EXT_REF_F1), M INDEX (PK_ITEMS_MAIN)), U INDEX (PK_USERS))

В автоматизированных конструкторах запросов, которые я сам пишу, я это учитываю, и все left join переставляю в конец. Геморой, но что поделать.
Но со всякими чужими ORM, которые сами создают запросы - беда.
Какие только извращения не приходится выдумывать, чтобы обойти этот баг.


>> И да "left join e ... where e. ..." вызывает недоумение

Зачем я так сделал, подробно написал в предыдущем посте: я полагался на то, что план будет построен вокруг индекса по m.F0, а условие по полю e.F1 будет обрабатываться не через индекс.

Сейчас переписал на +0 обращения к тем полям, по которым я не хочу использовать индекс.

[Обновления: Thu, 14 July 2022 11:35]

Известить модератора

Re: Изменения оптимизатора? [сообщение #192 является ответом на сообщение #182] Mon, 18 July 2022 03:09 Переход к предыдущему сообщениюПереход к следующему сообщению
kdv в настоящее время не в онлайне  kdv
Сообщений: 98
Зарегистрирован: June 2022
Member
не вижу ничего необычного в последних двух планах. left/right всегда выполняются строго "попарно". Поэтому оптимизатор сначала делает left, а потом делает inner. Если же вначале стоят inner, то у оптимизатора уже есть некая свобода действий.
А plan m natural потому что m left join, а дальше идет только условие объединения и фильтрация по e. Сервер никак тут не может использовать индексы по m, просто некуда. А left означает "взять все записи слева". Ну и ...
Re: Изменения оптимизатора? [сообщение #197 является ответом на сообщение #192] Mon, 18 July 2022 08:45 Переход к предыдущему сообщениюПереход к следующему сообщению
dimitr в настоящее время не в онлайне  dimitr
Сообщений: 18
Зарегистрирован: July 2022
Junior Member
По-моему, топикстартер забыл нам сказать, что у него не совсем Firebird... а на самом деле HQbird. Быстрое решение - обновиться на последнюю версию. Правильное решение - не использовать LEFT JOIN для хинтования.
Re: Изменения оптимизатора? [сообщение #199 является ответом на сообщение #197] Mon, 18 July 2022 13:40 Переход к предыдущему сообщениюПереход к следующему сообщению
sim_84 в настоящее время не в онлайне  sim_84
Сообщений: 332
Зарегистрирован: June 2022
Senior Member
>>>> Кстати есть наработки которые превращают такие left в inner join.

>> Видимо, я на такую наработку и нарвался.

Чтобы на такую наработку нарваться у тебя должен быть HQBird, а не Firebird.

dimitr,

кстати насчёт превращения left в inner. Насколько я понял оно пока работает только непосредственно с той таблицей что присоединена по left join, но не каскадно. То есть вот так

select *
from a 
left join b on b.id = a.id_b
where b.f = 1
превращается в

select *
from a 
join b on b.id = a.id_b
where b.f = 1
А вот такой запрос

select *
from a 
left join b on b.id = a.id_b
left join c on c.id = b.id_c
where c.f = 1
превратится в

select *
from (select *
from a 
left join b on b.id = a.id_b) t
join c on c.id = t.id_c
where c.f = 1
а не в

select *
from a 
join b on b.id = a.id_b
join c on c.id = b.id_c
where c.f = 1
Re: Изменения оптимизатора? [сообщение #201 является ответом на сообщение #199] Mon, 18 July 2022 18:12 Переход к предыдущему сообщениюПереход к следующему сообщению
dimitr в настоящее время не в онлайне  dimitr
Сообщений: 18
Зарегистрирован: July 2022
Junior Member
Да, пока только напрямую.
Re: Изменения оптимизатора? [сообщение #206 является ответом на сообщение #192] Tue, 19 July 2022 14:32 Переход к предыдущему сообщениюПереход к следующему сообщению
optimiz94 в настоящее время не в онлайне  optimiz94
Сообщений: 15
Зарегистрирован: July 2022
Junior Member
kdv писал(а) Mon, 18 July 2022 03:09
не вижу ничего необычного в последних двух планах. left/right всегда выполняются строго "попарно". Поэтому оптимизатор сначала делает left, а потом делает inner. Если же вначале стоят inner, то у оптимизатора уже есть некая свобода действий.
А plan m natural потому что m left join, а дальше идет только условие объединения и фильтрация по e. Сервер никак тут не может использовать индексы по m, просто некуда. А left означает "взять все записи слева". Ну и ...
Но это какие-то внутренние заморочки движка. У MS SQL Server нет этой проблемы.
Вручную это всё можно учитывать и переставлять join-ы местами.
Но вот с ORM такой гибкости нет, приходится либо разбивать на несколько запросов, либо извращаться.

Например, на задачу "достань мне все заказы пользователей из Владивостока", ORM сделает запрос с планом (O NATURAL).
select ...
from Orders o
left join ... опциональные расширения к заказу в схеме данных
join Cities c on c.Id=o.CityId
where c.Id=?pCity
Приходится переформулировать как "достань мне город Владивосток и зафетчи его заказы"

dimitr писал(а) Mon, 18 July 2022 08:45
По-моему, топикстартер забыл нам сказать, что у него не совсем Firebird... а на самом деле HQbird
Думал, будет понятно из номеров версий публичных релизов.

[Обновления: Tue, 19 July 2022 15:24]

Известить модератора

Re: Изменения оптимизатора? [сообщение #212 является ответом на сообщение #206] Wed, 20 July 2022 09:28 Переход к предыдущему сообщениюПереход к следующему сообщению
sim_84 в настоящее время не в онлайне  sim_84
Сообщений: 332
Зарегистрирован: June 2022
Senior Member
Никогда не ставь inner join после left join.

Оптимизатор пока не умеет самостоятельно поднимать inner join выше left join
Re: Изменения оптимизатора? [сообщение #213 является ответом на сообщение #212] Wed, 20 July 2022 11:14 Переход к предыдущему сообщениюПереход к следующему сообщению
optimiz94 в настоящее время не в онлайне  optimiz94
Сообщений: 15
Зарегистрирован: July 2022
Junior Member
Я сам и не ставлю.
Но что делать с Hibernate, который одну сущность всегда транслирует в набор фиксированных join-ов

Например
from Orders o -- главная таблица заказов
left join Order_Ext_Info -- дополнительные необязательные атрибуты заказа
join Order_Misc_Info -- дополнительные обязательные атрибуты заказа
-- а дальше генерируются join-ы к другим сущностям, по тому же принципу: "набор таблиц одной сущности идёт вместе одним блоком"
join Clients c --- джойним клиентов, чтобы наложить по ним критерий
left join Client_Ext_Info -- дополнительные необязательные атрибуты клиента
--
where c.FIO = 'Иванов'
Приходится в объектной модели делать всякие лишние связи (например, у города список заказов, открытых в этом городе), чтобы иметь возможность играться с разными вариантами HQL, пока оно не транслируется в хороший SQL.
Re: Изменения оптимизатора? [сообщение #377 является ответом на сообщение #213] Wed, 24 August 2022 02:20 Переход к предыдущему сообщению
Старый Плюшев в настоящее время не в онлайне  Старый Плюшев
Сообщений: 95
Зарегистрирован: August 2022
Географическое положение: Ленинград
Member
За как превратить SQL в HQL (или наоборот?) ничего не скажу, но что важно - не надо путать использование/неиспользование индекса с порядком и способом перебора таблиц. Классический left перебирает ведущую таблицу целиком в рамках условий в where на ней и присоединяет данные из ведомой, не найдёт - присоединяет нуллы, поэтому индексы на ведомой по условиям в where и не используются - эти условия в left применяются не к данным в таблице, а к данным в резалтсете, где никаких индексов уже и в помине нет. Это побочный эффект, так сказать. Вот насчёт "проталкивания" я заинтересовался. Это что, типа закадровый перенос каких-то условий из where в on? Но тогда надо where в таком запросе дополнять is not null чтобы получить классический результат. Или как?
Предыдущая тема: Проблемное арифметическое выражение
Следующая тема: Нужна помощь с проектированием базы
Переход к форуму:
  


Текущее время: Tue Dec 24 06:45:54 GMT+3 2024

Общее время, затраченное на создание страницы: 0.01242 секунд