|
|
|
Есть ли разница, в каком месте делать группировку?
|
|||
|---|---|---|---|
|
#18+
Подскажите, как сделать оптимальнее? Есть таблица clients со списком клиентов. Есть таблица services со списком услуг клиентов (services.client_id = clients.client_id). Есть таблица charges со списком начислений по услугам (charges.service_id = services.service_id). Первые две таблицы небольшие (до 10к записей), последняя таблица довольно большая (порядка 500кк). Мне нужно отобрать услуги, по которым не было начислений за последние три месяца. Есть ли разница, где делать группировку? Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. Код: plsql 1. 2. 3. 4. 5. 6. ________________________ Мы смотрим с оптимизмом... ...в оптический прицел. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2017, 16:53 |
|
||
|
Есть ли разница, в каком месте делать группировку?
|
|||
|---|---|---|---|
|
#18+
Alibek B., Alibek B., я б делал через not exists (select 1 from charges c where c.service_id = services.service_id and c.c.last_date < sysdate-90 ...) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2017, 17:11 |
|
||
|
Есть ли разница, в каком месте делать группировку?
|
|||
|---|---|---|---|
|
#18+
stax.., ой c.c.last_date >= sysdate-90 ..... stax ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2017, 17:14 |
|
||
|
Есть ли разница, в каком месте делать группировку?
|
|||
|---|---|---|---|
|
#18+
Alibek B.Есть ли разница, где делать группировку?Гугли oracle query transformations view merging. Что мешает посмотреть план? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2017, 17:20 |
|
||
|
Есть ли разница, в каком месте делать группировку?
|
|||
|---|---|---|---|
|
#18+
Сервер боевой, я перед выполнением потенциально тяжелых запросов стараюсь предварительно совета спросить. По поводу not exists — мне нужно помимо самого факта начислений получить ссылку на начисление (идентификатор, сумма), поэтому я и рассматриваю варианты с join. А иначе действительно not exists выглядит более предпочтительным. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2017, 19:59 |
|
||
|
Есть ли разница, в каком месте делать группировку?
|
|||
|---|---|---|---|
|
#18+
Alibek B.Сервер боевой, я перед выполнением потенциально тяжелых запросов стараюсь предварительно совета спросить. По поводу not exists — мне нужно помимо самого факта начислений получить ссылку на начисление (идентификатор, сумма), поэтому я и рассматриваю варианты с join. А иначе действительно not exists выглядит более предпочтительным. другое дело (задача) лично я не знаю что посоветовать, реально попробовать, не положете ж Вы базу с одной стороны п2 все по индексах, но чуть больше сртировка с другой п1 подзапрос (без индексов,) обьедениние может быть и подольше имхо, пробуйте ..... stax ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2017, 21:05 |
|
||
|
Есть ли разница, в каком месте делать группировку?
|
|||
|---|---|---|---|
|
#18+
stax.., Станислав, ты в курсе что в CBO есть трансформации запросов и not exists может идти вложенными циклами по индексу, а может быть преобразован в anti join в зависимости от стоимости? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2017, 21:32 |
|
||
|
Есть ли разница, в каком месте делать группировку?
|
|||
|---|---|---|---|
|
#18+
dbms_photoshopstax.., Станислав, ты в курсе что в CBO есть трансформации запросов и not exists может идти вложенными циклами по индексу, а может быть преобразован в anti join в зависимости от стоимости? примерно в курсе, я не всегда вгадую во что он трансформирует пишу [not] exists мне так более понятен смысл запроса ps на счет задачки Alibek B., он уточнил что нужно несколько другое возможжно есть смысл ,max(case when last_date < sysdate-90 then 1 else 0 end) cc --1-не было начислений, 0-были .... stax ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.01.2017, 15:29 |
|
||
|
Есть ли разница, в каком месте делать группировку?
|
|||
|---|---|---|---|
|
#18+
Не удалось придумать нормального решения, чтобы заодно получить ссылку на последнее начисление (сумму, дату, идентификатор). Пришлось отказаться от этого и обойтись проверкой на exists. Но все же хотелось бы иметь возможность получить хотя бы список идентификаторов записей, которые попадают под такую проверку, поэтому составил такой запрос: Код: plsql 1. 2. 3. 4. 5. 6. 7. Данные возвращаются правильные, но запрос выполняется 3-4 минуты. explain plan такой: Код: plaintext 1. 2. 3. 4. На мой взгляд оптимизировать особо нечего, но может быть я что-то упускаю? Если сделать просто Код: plsql 1. 2. 3. 4. 5. 6. то запрос выполняется гораздо быстрее (почти моментально), но мне его использовать нужно будет в нескольких местах и при использовании с not exists (select ...) суммарно тоже получается долго. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2017, 13:02 |
|
||
|
Есть ли разница, в каком месте делать группировку?
|
|||
|---|---|---|---|
|
#18+
Помогите интерпретировать планы выполнения. Составил три варианта, все три варианта выполняются примерно одинаковое время (около трех секунд). Какой из вариантов лучше? Первый вариант: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. Второй вариант: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. Код: plaintext 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. Третий вариант: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. Мне второй вариант более удобен для использования, но зато третий вариант чуть короче. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2017, 13:49 |
|
||
|
Есть ли разница, в каком месте делать группировку?
|
|||
|---|---|---|---|
|
#18+
В общем остановился на втором варианте. В третьем варианте мне потом все равно нужно избавляться от дублирования строк (в CUSTOMERS), так что шило на мыло получается. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.01.2017, 10:20 |
|
||
|
Есть ли разница, в каком месте делать группировку?
|
|||
|---|---|---|---|
|
#18+
первый вариант отработает быстрее. И будет меньше потоков сервера жрать. Так как во втором варианте запрос сначала все что есть вытащит, сцепит и потом только всю массу будет группировать. В первом же варианте сначала все сгруппирует, а потом вытащит и сцепет. Если сильно не хочешь грузить сервер, ставь хинт - select /* no parallel */... будет в одном потоке выполнятся. Почти не напряжет сервак, но будет долго отрабатываться. Ну или можешь поставить select /* parallel(30) */...from, где 30 это количество потоков отработки. Если не ставить, то по умолчанию берется около 1000 потоков, но работают из них 100-250, остальные в резерве. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.01.2017, 12:16 |
|
||
|
Есть ли разница, в каком месте делать группировку?
|
|||
|---|---|---|---|
|
#18+
multidron1Если не ставить, то по умолчанию берется около 1000 потоков, но работают из них 100-250, остальные в резерве.И сколько БД ты, обобщающий наш, успел повидать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.01.2017, 12:29 |
|
||
|
Есть ли разница, в каком месте делать группировку?
|
|||
|---|---|---|---|
|
#18+
Elic, я забыл упомянуть что это по умолчанию. Зачастую в 80% так и стоит. Уже несколько лет занимаюсь тем, что ускоряю и оптимизирую процессы в банках. Например ускорил рассмотрение заявок на выдачу кредитов с 15 минут до 11. Там все БД считает по правилам. Ускорил обновления витрин с 8 часов до 5. В общем еще дохрена чего. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2017, 06:42 |
|
||
|
|

start [/forum/topic.php?fid=52&fpage=178&tid=1886545]: |
0ms |
get settings: |
8ms |
get forum list: |
16ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
61ms |
get topic data: |
10ms |
get forum data: |
4ms |
get page messages: |
57ms |
get tp. blocked users: |
2ms |
| others: | 234ms |
| total: | 400ms |

| 0 / 0 |
