|
Сложный запрос
|
|||
---|---|---|---|
#18+
YuRockсчитаешь чушью (как ты и написал), что left легче inner? что значит "легче"? "тяжесть" выполнения запроса зависит от плана. left/right приводят к принудительному порядку объединения таблиц. А у inner или неявных join сервер может сам определить порядок объединения таблиц. Так что да - про "легче" это если не чушь, то собственная терминология, которая далека от реальности. Сравнивать принудительный порядок и произвольный? Да еще учитывая, что планы могут оказаться одинаковыми. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.06.2017, 11:59 |
|
Сложный запрос
|
|||
---|---|---|---|
#18+
YuRockЕсли есть возможность, лучше заменять их на left/right [outer] join'ы - они работают "в один проход" при чем "с нужной стороны", в отличие от inner. например, вот это чушь. То есть, inner работает "в два прохода", что-ли? Одинаково они работают, просто генерируют разные планы (а иногда и одинаковые). Через left/right ты просто можешь принудительно "задать план", который "работает быстрее". p.s. про "работает быстрее" - зависит от того, выбирается несколько первых записей, или fetch all. Один и тот же массив записей может выбираться разное время, в зависимости от плана запроса (методов доступа). рекомендую перечитать http://www.ibase.ru/dataaccesspaths/ как минимум пункт 3.1 ... |
|||
:
Нравится:
Не нравится:
|
|||
01.06.2017, 12:05 |
|
Сложный запрос
|
|||
---|---|---|---|
#18+
YuRockСдесь же ТС обратился с просьбой дать идеи, как попробовать оптимизировать запрос, который выполняется "оооочень долго". Ты план запроса видел? Вполне возможно надо просто где-то индекс создать, может +0, а может и вовсе запрос переписать. А ты свои left join без причины пытаешься воткнуть. То что starting with не может использовать индекс тоже чушь. И то что left "легче" inner я действительно считаю чушью. З.Ы. Тут никто не пытается тебя оскорбить или ущемить твоё самолюбие, но ты действительно не сечёшь фишку. Почитай приведённую kdv статью. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.06.2017, 12:22 |
|
Сложный запрос
|
|||
---|---|---|---|
#18+
Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38.
На данный момент вот такой запрос, он отрабатывает быстрее чем с exists, но совсем неправильно Например один человек сходил 3 раза в поликлинику, 28.03 - sl.id = 1, 10.04 -sl.id = 2, 13.04 - sl.id = 3. Запрос отрабатывает таким образом, что в результате находятся пары 1 - 2, 2 - 3. То есть вместо трех отбираются четыре 1,2,2,3. Это можно как-то исправить? ... |
|||
:
Нравится:
Не нравится:
|
|||
01.06.2017, 12:24 |
|
Сложный запрос
|
|||
---|---|---|---|
#18+
Кареглазая_зая, версия сервера какая? ... |
|||
:
Нравится:
Не нравится:
|
|||
01.06.2017, 12:36 |
|
Сложный запрос
|
|||
---|---|---|---|
#18+
Симонов Денис, 2.1. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.06.2017, 13:00 |
|
Сложный запрос
|
|||
---|---|---|---|
#18+
kdvнапример, вот это чушь. То есть, inner работает "в два прохода", что-ли? Одинаково они работают, просто генерируют разные планы (а иногда и одинаковые). Через left/right ты просто можешь принудительно "задать план", который "работает быстрее". Как минимум я отключаю работу оптимизитора (для этого момента), а так же страхуюсь от его возможных ошибок. Кстати, сейчас провел некоторые тесты своих запросов 14-летней давности на тройке, поменял LEFT на INNER. И, да, план и быстродействие оказались одинаковыми. В то время такого щастья не было, отсюда и привычка "заранее отсекать неверный план". Вот честно, мне сейчас очень сложно будет перестроиться и НЕ писать LEFT там, где я уверен, что он будет оптимален. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.06.2017, 13:09 |
|
Сложный запрос
|
|||
---|---|---|---|
#18+
YuRock, не ну 14 лет назад оптимизатор был так себе. Сейчас намного лучше. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.06.2017, 13:15 |
|
Сложный запрос
|
|||
---|---|---|---|
#18+
Симонов ДенисТы план запроса видел? Вполне возможно надо просто где-то индекс создать, может +0, а может и вовсе запрос переписать. А ты свои left join без причины пытаешься воткнуть. Как оказалось, версия 2.1, а на ней оптимизатор еще не тот, что сейчас. План, конечно, смотреть надо. Симонов ДенисТо что starting with не может использовать индекс тоже чушь. Ты цитируешь то, что я НЕ писал. Я писал: " not starting with" а так же "индекс сомневаюсь, что получится использовать". Симонов ДенисИ то что left "легче" inner я действительно считаю чушью. Возможно сейчас, когда оптимизатор стал достаточно хорош, это и так. А раньше план мог измениться в "неправильную сторону" просто при накоплении данных в базу, и приходилось его "направлять", и поэтому лучше было сразу так делать. Симонов ДенисЗ.Ы. Тут никто не пытается тебя оскорбить или ущемить твоё самолюбие Это я понимаю прекрасно, тут все на нервах постоянно) ... |
|||
:
Нравится:
Не нравится:
|
|||
01.06.2017, 13:17 |
|
Сложный запрос
|
|||
---|---|---|---|
#18+
YuRockСимонов ДенисТо что starting with не может использовать индекс тоже чушь. Ты цитируешь то, что я НЕ писал. Я писал: " not starting with" а так же "индекс сомневаюсь, что получится использовать". Уже и не сомневаюсь. Проверил только что на 3.0.1, который у меня в продакшене: Код: sql 1. 2. 3.
Планы такие: PLAN (C NATURAL) и если NOT убрать: PLAN (C INDEX (PK_COMMANDS)) есть PRIMARY KEY (COMMAND_ID), COMMAND_ID CHAR(4) NOT NULL ... |
|||
:
Нравится:
Не нравится:
|
|||
01.06.2017, 13:23 |
|
Сложный запрос
|
|||
---|---|---|---|
#18+
YuRock, not я проглядел, там в принципе индекс проблематично использовать ... |
|||
:
Нравится:
Не нравится:
|
|||
01.06.2017, 13:27 |
|
Сложный запрос
|
|||
---|---|---|---|
#18+
Кареглазая_зая, Мда, тут уже проще выполнить в процедуре наиболее простой запрос с этими страшными условиями, отстртировав по "НомеруПолиса,Дате", и затем в цикле инсертить, если надо. Так хотя бы наглядно будет. Другое дело, как в процедуру эти условия передавать трёхэтажные.. Их лучше в отдельной таблице хранить - как "настройки отчета". ... |
|||
:
Нравится:
Не нравится:
|
|||
01.06.2017, 14:07 |
|
Сложный запрос
|
|||
---|---|---|---|
#18+
Симонов Денисне ну 14 лет назад оптимизатор был так себе. Сейчас намного лучше."Так себе" только по сравнению с новым. Работал и ладно. Всегда как-то хватало псевдо-хинтов, да и то нечасто. Вот чтобы LEFT приходилось писать - это только когда с процедурой соединение, других случаев не припоминаю. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.06.2017, 15:20 |
|
|
start [/forum/topic.php?fid=40&msg=39463721&tid=1561558]: |
0ms |
get settings: |
11ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
161ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
57ms |
get tp. blocked users: |
2ms |
others: | 296ms |
total: | 565ms |
0 / 0 |