Как еще можно оптимизировать запрос? / Oracle

ReSQL.ru

Мобильная версия Контакт Правила FAQ Помощь

Гость

Войти | Регистрация | Профиль | Очистить

Новые сообщения | Избранное

Форумы | Пользователи | Статистика | Мод. лог | Поиск

Цитировать

Написать

Автор*:

Ввести пароль для входа

Тема*:

Сообщение

Данное сообщение тематическое

Сообщение содержит картинки или видео 18+

Автор:

ВНИМАНИЕ! На данном подфоруме действуют строгие правила. Удостоверьтесь, что ваше сообщение соответствует им!

Форум или тема закрыты для гостей. Необходима авторизация!

Загрузить последнюю сохраненную версию

Вложение:

Вставить как галерею

Максимальный размер вложений: 4,0 МБ, аудио/видео: 8,0 МБ. Картинки большего размера ужимаются, если возможно.

Введите код, изображенный на картинке. Если код нечитаемый, кликните картинку, чтобы загрузить другой вариант.

Отправляя сообщение, я выражаю свое согласие с правилами форума и принимаю пользовательское соглашение.

Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр

Форумы / Oracle [игнор отключен] [закрыт для гостей] / Как еще можно оптимизировать запрос?

24 сообщений из 24, страница 1 из 1

Как еще можно оптимизировать запрос?

#39729331

x17.mstu

Участник

Сообщения: 365

Рейтинг: 0 / 0

Код: plsql

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.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.

SELECT fu.ISSUE_UBS_ID, fu.ISSUE_ACTIVE, ul.issue_cins CINS, ul.issue_cusip CUSIP, ul.issue_isin ISIN, LTRIM(ul.issue_valoren,'0') VALOREN, 
fu.undl_issue_ubs_id UNDL_UBS_ID, ul.UNDL_ACTIVE, fu.UNDL_ISIN, fu.UNDL_CHEAPEST_TO_DELIVER_ISIN 
FROM
(SELECT 
distinct ISSUE_UBS_ID, undl_issue_ubs_id, undl_cheapest_to_deliver_isin, undl_isin , issue_active
From rddh_future_stg
where IS_INCREMENTAL='N' and undl_issue_ubs_id is not null
and substr(case when issue_iso_cfi_2015 is null then issue_iso_cfi else issue_iso_cfi_2015 end,1,1)='F'
) fu 
inner join
(SELECT distinct ISSUE_UBS_ID, issue_valoren, issue_cins, issue_cusip, issue_isin, issue_active undl_active From rddh_equity_stg 
WHERE IS_INCREMENTAL='N') ul 
on fu.undl_issue_ubs_id = ul.ISSUE_UBS_ID 
where 
(('Y' = 'N') 
OR  ('Y' = 'Y' 
	AND EXISTS (SELECT i.ISSUE_UBS_ID FROM INST_INCREMENTAL i 
		WHERE (i.ASSET_CLASS_SHORT = 'RDFUTR' AND i.ISSUE_UBS_ID=fu.ISSUE_UBS_ID) 
			OR (i.ASSET_CLASS_SHORT = 'RDEQTY' AND i.ISSUE_UBS_ID=ul.ISSUE_UBS_ID))))
union all
SELECT fu.ISSUE_UBS_ID, fu.ISSUE_ACTIVE, ul.issue_cins CINS, ul.issue_cusip CUSIP, ul.issue_isin ISIN, LTRIM(ul.issue_valoren,'0') VALOREN, 
fu.undl_issue_ubs_id UNDL_UBS_ID, ul.UNDL_ACTIVE, fu.UNDL_ISIN, fu.UNDL_CHEAPEST_TO_DELIVER_ISIN 
FROM
(SELECT 
distinct ISSUE_UBS_ID, undl_issue_ubs_id, undl_cheapest_to_deliver_isin, undl_isin , issue_active
From rddh_future_stg
where IS_INCREMENTAL='N' and undl_issue_ubs_id is not null
and substr(case when issue_iso_cfi_2015 is null then issue_iso_cfi else issue_iso_cfi_2015 end,1,1)='F'
) fu 
inner join
(SELECT distinct ISSUE_UBS_ID, issue_valoren, null issue_cins, null issue_cusip, issue_isin, issue_active undl_active From rddh_equity_index_stg 
WHERE IS_INCREMENTAL='N') ul 
on fu.undl_issue_ubs_id = ul.ISSUE_UBS_ID 
where 
(('Y' = 'N') 
OR  ('Y' = 'Y' 
	AND EXISTS (SELECT i.ISSUE_UBS_ID FROM INST_INCREMENTAL i 
		WHERE (i.ASSET_CLASS_SHORT = 'RDFUTR' AND i.ISSUE_UBS_ID=fu.ISSUE_UBS_ID) 
			OR (i.ASSET_CLASS_SHORT = 'RDEQIX' AND i.ISSUE_UBS_ID=ul.ISSUE_UBS_ID))))
union all

SELECT 
distinct 
fu.ISSUE_UBS_ID, fu.ISSUE_ACTIVE, NULL CINS, NULL CUSIP, NULL ISIN, NULL VALOREN, 
NULL UNDL_UBS_ID, fu.issue_active UNDL_ACTIVE, fu.UNDL_ISIN, fu.UNDL_CHEAPEST_TO_DELIVER_ISIN 
From rddh_future_stg fu 
where fu.undl_issue_ubs_id is null AND (fu.undl_cheapest_to_deliver_isin is not null or fu.undl_isin is not null)
AND fu.IS_INCREMENTAL='N' 
and substr(case when fu.issue_iso_cfi_2015 is null then fu.issue_iso_cfi else fu.issue_iso_cfi_2015 end,1,1)='F'
AND 
(('Y' = 'N') OR 
('Y' = 'Y' AND EXISTS (SELECT i.ISSUE_UBS_ID FROM INST_INCREMENTAL i WHERE i.ASSET_CLASS_SHORT = 'RDFUTR' AND i.ISSUE_UBS_ID=fu.ISSUE_UBS_ID)));

...

Рейтинг:

0 / 0

07.11.2018, 14:39

| Ответить | Цитировать | Написать

Как еще можно оптимизировать запрос?

#39729333

x17.mstu

Участник

Сообщения: 365

Рейтинг: 0 / 0

Код: plsql

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.
39.
40.
41.
42.
43.
44.

Plan hash value: 2282276351
 
---------------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                             | Name                  | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     | Pstart| Pstop |
---------------------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                      |                       | 31569 |    12M|       |   800M  (5)|999:59:59 |       |       |
|   1 |  UNION-ALL                            |                       |       |       |       |            |          |       |       |
|*  2 |   FILTER                              |                       |       |       |       |            |          |       |       |
|   3 |    MERGE JOIN                         |                       |   553K|   110M|       | 70342  (47)| 00:16:25 |       |       |
|   4 |     SORT JOIN                         |                       |  1407K|   165M|       | 65673  (49)| 00:15:20 |       |       |
|   5 |      VIEW                             |                       |  1407K|   165M|       | 65673  (49)| 00:15:20 |       |       |
|   6 |       HASH UNIQUE                     |                       |  1407K|   167M|   194M| 65673  (49)| 00:15:20 |       |       |
|   7 |        PARTITION LIST SINGLE          |                       |  1407K|   167M|       | 43241  (74)| 00:10:06 |   KEY |   KEY |
|   8 |         TABLE ACCESS STORAGE FULL     | RDDH_EQUITY_STG       |  1407K|   167M|       | 43241  (74)| 00:10:06 |     2 |     2 |
|*  9 |     SORT JOIN                         |                       | 71745 |  6095K|    14M|  4669  (13)| 00:01:06 |       |       |
|  10 |      VIEW                             |                       | 71745 |  6095K|       |  3847  (15)| 00:00:54 |       |       |
|  11 |       HASH UNIQUE                     |                       | 71745 |  7076K|  8784K|  3847  (15)| 00:00:54 |       |       |
|  12 |        PARTITION LIST SINGLE          |                       | 71745 |  7076K|       |  2902  (19)| 00:00:41 |   KEY |   KEY |
|* 13 |         TABLE ACCESS STORAGE FULL     | RDDH_FUTURE_STG       | 71745 |  7076K|       |  2902  (19)| 00:00:41 |     2 |     2 |
|  14 |    INLIST ITERATOR                    |                       |       |       |       |            |          |       |       |
|* 15 |     TABLE ACCESS BY GLOBAL INDEX ROWID| INST_INCREMENTAL      |   155K|  4088K|       |  1403   (5)| 00:00:20 | ROWID | ROWID |
|* 16 |      INDEX RANGE SCAN                 | INST_INCREMENTAL_IDX  |   124K|       |       |   357   (1)| 00:00:05 |       |       |
|* 17 |   FILTER                              |                       |       |       |       |            |          |       |       |
|* 18 |    HASH JOIN                          |                       | 71745 |    11M|  6240K|  5412  (11)| 00:01:16 |       |       |
|  19 |     VIEW                              |                       | 67159 |  5443K|       |  1013   (3)| 00:00:15 |       |       |
|  20 |      HASH UNIQUE                      |                       | 67159 |  5312K|  6352K|  1013   (3)| 00:00:15 |       |       |
|  21 |       PARTITION LIST SINGLE           |                       | 67159 |  5312K|       |   285   (8)| 00:00:04 |   KEY |   KEY |
|  22 |        TABLE ACCESS STORAGE FULL      | RDDH_EQUITY_INDEX_STG | 67159 |  5312K|       |   285   (8)| 00:00:04 |     2 |     2 |
|  23 |     VIEW                              |                       | 71745 |  6095K|       |  3847  (15)| 00:00:54 |       |       |
|  24 |      HASH UNIQUE                      |                       | 71745 |  7076K|  8784K|  3847  (15)| 00:00:54 |       |       |
|  25 |       PARTITION LIST SINGLE           |                       | 71745 |  7076K|       |  2902  (19)| 00:00:41 |   KEY |   KEY |
|* 26 |        TABLE ACCESS STORAGE FULL      | RDDH_FUTURE_STG       | 71745 |  7076K|       |  2902  (19)| 00:00:41 |     2 |     2 |
|  27 |    INLIST ITERATOR                    |                       |       |       |       |            |          |       |       |
|* 28 |     TABLE ACCESS BY GLOBAL INDEX ROWID| INST_INCREMENTAL      | 37953 |  1000K|       |   387  (15)| 00:00:06 | ROWID | ROWID |
|* 29 |      INDEX RANGE SCAN                 | INST_INCREMENTAL_IDX  | 30362 |       |       |   357   (1)| 00:00:05 |       |       |
|  30 |   HASH UNIQUE                         |                       |   299 | 38272 |       |  3243  (18)| 00:00:46 |       |       |
|* 31 |    HASH JOIN SEMI                     |                       |   299 | 38272 |       |  3242  (18)| 00:00:46 |       |       |
|  32 |     JOIN FILTER CREATE                | :BF0000               |   299 | 30199 |       |  2902  (19)| 00:00:41 |       |       |
|  33 |      PARTITION LIST SINGLE            |                       |   299 | 30199 |       |  2902  (19)| 00:00:41 |   KEY |   KEY |
|* 34 |       TABLE ACCESS STORAGE FULL       | RDDH_FUTURE_STG       |   299 | 30199 |       |  2902  (19)| 00:00:41 |     2 |     2 |
|  35 |     JOIN FILTER USE                   | :BF0000               |   206K|  5457K|       |   339  (10)| 00:00:05 |       |       |
|  36 |      PARTITION LIST SINGLE            |                       |   206K|  5457K|       |   339  (10)| 00:00:05 |   KEY |   KEY |
|* 37 |       TABLE ACCESS STORAGE FULL       | INST_INCREMENTAL      |   206K|  5457K|       |   339  (10)| 00:00:05 |     3 |     3 |
---------------------------------------------------------------------------------------------------------------------------------------

...

Рейтинг:

0 / 0

07.11.2018, 14:40

| Ответить | Цитировать | Написать

Как еще можно оптимизировать запрос?

#39729341

x17.mstu

Участник

Сообщения: 365

Рейтинг: 0 / 0

Может предварительно все те поля которые по distinct засунуть в отедльные таблицы ?

...

Рейтинг:

0 / 0

07.11.2018, 14:56

| Ответить | Цитировать | Написать

Как еще можно оптимизировать запрос?

#39730523

Вадиман

Участник

Откуда: Владивосток

Сообщения: 988

Рейтинг: 0 / 0

Ни одной попытки локализовать проблему и уменьшить тест-кейс.
На что надеется автор?

...

Рейтинг:

0 / 0

09.11.2018, 13:04

| Ответить | Цитировать | Написать

Как еще можно оптимизировать запрос?

#39730587

andrey_anonymous

Участник

Откуда: Москва

Сообщения: 18 719

Рейтинг: 0 / 0

x17.mstuМожет предварительно
Предварительно выбросьте весь хлам из запроса и уберите ненужный дубляж.
Нагородили целый роман там, где достаточно пол-странички текста.
По максимуму уберите OR-условия.
Потом можно будет говорить про какую-либо оптимизацию.

...

Рейтинг:

0 / 0

09.11.2018, 14:30

| Ответить | Цитировать | Написать

Как еще можно оптимизировать запрос?

#39730642

MaximaXXL

Участник

Откуда: Киев

Сообщения: 653

Рейтинг: 0 / 0

x17.mstu,

тема "Как еще можно оптимизировать запрос? "

т.е. Вы утверждаете что Вы его УЖЕ оптимизировали?
Тогда какого результата Вы пытаетесь достичь?
Чтоб он не отработал за 2 недели (стандартное время на увольнение)?

...

Рейтинг:

0 / 0

09.11.2018, 15:12

| Ответить | Цитировать | Написать

Как еще можно оптимизировать запрос?

#39731848

julat21

Участник

Сообщения: 49

Рейтинг: 0 / 0

x17.mstu,
'Y' = 'N' Что это за условие такое?
Здесь надо максимально вынести общее, которое повторяется в каждом Union в отдельный запрос, дальше уже его результат использовать в разных вариациях. Также по поводу Exists, здесь могут быть варианты, все зависит от данных которые убиваются при inner join, возможно оптимальней будет отфильтровать по исходному множеству, чем по результату. Например в первом множестве будет 10 одинаковых ISSUE_UBS_ID и такие же 20 ISSUE_UBS_ID во втором, в результате после inner join необходимо проверять все 20*10, куда оптимальней было б проверять не 200, а изначально 20+10 и не делать кучу лишних движений...

...

Рейтинг:

0 / 0

12.11.2018, 16:19

| Ответить | Цитировать | Написать

Как еще можно оптимизировать запрос?

#39731861

merch

Участник

Сообщения: 170

Рейтинг: 0 / 0

x17.mstu, горю желанием оптимизировать твой запрос, но вот на бумажке запутался, а выполняю на тестовой БД, ловлю

Код: plsql

1.
2.

ORA-00942 
table or view does not exist

Не знаешь в чем может быть проблема?

...

Рейтинг:

0 / 0

12.11.2018, 16:32

| Ответить | Цитировать | Написать

Как еще можно оптимизировать запрос?

#39731899

-2-

Участник

Сообщения: 15 349

Рейтинг: 0 / 0

julat21'Y' = 'N' Что это за условие такое?Даже не имея опыта в разнообразии систем, можно заметить подобное среди множества тем на sql.ru.

julat21после inner join необходимо проверять все 20*10Великий трансформатор, что ни джоин, то cross? Хотя да будет быстрее. После фильтра обоих источников джоин ничего не вернет и вообще ничего проверять не придется.
А вот применить фильтр только к одной таблице можно.

...

Рейтинг:

0 / 0

12.11.2018, 16:59

| Ответить | Цитировать | Написать

Как еще можно оптимизировать запрос?

#39731912

julat21

Участник

Сообщения: 49

Рейтинг: 0 / 0

-2-, не такой большой опыт посещения сайта как у Вас, не понимаю применения условия которое заведемо ложно. Дайте ссылку или расстолкуйте для чего это нужно?

...

Рейтинг:

0 / 0

12.11.2018, 17:06

| Ответить | Цитировать | Написать

Как еще можно оптимизировать запрос?

#39731923

dmdmdm

Участник

Откуда: Нижний Новгород

Сообщения: 1 928

Рейтинг: 0 / 0

julat21не понимаю применения условия которое заведемо ложно

Запрос, вероятнее всего, формируется приложением по некоторым условиям.
И если условие командует "этот кусок данных не использовать", включается ложное условие "1=0".

...

Рейтинг:

0 / 0

12.11.2018, 17:23

| Ответить | Цитировать | Написать

Как еще можно оптимизировать запрос?

#39731925

julat21

Участник

Сообщения: 49

Рейтинг: 0 / 0

-2-,
Не совсем Вас понял
Вариант 1. Есть множество 1, которое пересекается с множеством 2 по опеределенному полю. Результат по этому полю проверяется со множеством 3.

Вариант 2. Если изначально проверить множетсво 1 с множеством 3, потом 2 с множеством 3 и их подрезультат пересечь, то мы получим тот же результат, что в варианте 1.

Например 10 мешков яблок, 20 мешков картошки, 15 мешков лука одно множество.
Второе множество допустим 5 мешков яблок, 25 мешков картошки, 10 мешков лука.

Третье множество это три машины, что должны везти товар: яблок, картошки, лука.

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

...

Рейтинг:

0 / 0

12.11.2018, 17:25

| Ответить | Цитировать | Написать

Как еще можно оптимизировать запрос?

#39731928

julat21

Участник

Сообщения: 49

Рейтинг: 0 / 0

dmdmdm,
Обычно в таком случае поступают так ((flag= 'N')
OR (flag = 'Y' ...))
Где flag внешняя переменная которая, которая управляет внутренней логикой. Но здесь написано прямо в лоб 'Y' = 'N', поэтому и возник вопрос.

...

Рейтинг:

0 / 0

12.11.2018, 17:29

| Ответить | Цитировать | Написать

Как еще можно оптимизировать запрос?

#39731933

dmdmdm

Участник

Откуда: Нижний Новгород

Сообщения: 1 928

Рейтинг: 0 / 0

julat21Обычно в таком случае поступают так ((flag= 'N')

Для машины что " 1 = 0 ", что " flag = 'N' ", без разницы.

А раз вы задаете подобные вопросы, и пытаетесь оптимизировать многоэтажный запрос с помощью форума, а не нескольких лет практики под руководством опытного товарища, вам в ответ и пишут всякие колкости.

...

Рейтинг:

0 / 0

12.11.2018, 17:34

| Ответить | Цитировать | Написать

Как еще можно оптимизировать запрос?

#39731938

julat21

Участник

Сообщения: 49

Рейтинг: 0 / 0

dmdmdm, Будьте внимательней. Это не я пытаюсь запрос оптимизировать...

...

Рейтинг:

0 / 0

12.11.2018, 17:37

| Ответить | Цитировать | Написать

Как еще можно оптимизировать запрос?

#39731945

dmdmdm

Участник

Откуда: Нижний Новгород

Сообщения: 1 928

Рейтинг: 0 / 0

julat21Будьте внимательней.

Буду.
Мой ответ "без разницы" в таком случае адресован и вам.

...

Рейтинг:

0 / 0

12.11.2018, 17:41

| Ответить | Цитировать | Написать

Как еще можно оптимизировать запрос?

#39731949

-2-

Участник

Сообщения: 15 349

Рейтинг: 0 / 0

dmdmdmjulat21не понимаю применения условия которое заведемо ложно

Запрос, вероятнее всего, формируется приложением по некоторым условиям.
И если условие командует "этот кусок данных не использовать", включается ложное условие "1=0".Не, настолько витиевато динамически учитывать через and или or записано целевое выражение, я бы не смог.

...

Рейтинг:

0 / 0

12.11.2018, 17:42

| Ответить | Цитировать | Написать

Как еще можно оптимизировать запрос?

#39731974

Valergrad

Участник

Сообщения: 601

Рейтинг: 0 / 0

Хех, судя по названию переменных - вы работаете в финансовом секторе UBS. Надо помочь коллеге с параллельного проекта))

В целом, расследование тормозящего запроса начинается с анализа - какая конкретно строчка занимает время.

Для начала: Оптимизатор считает что это вторая строчка - FILTER. Так как ему нужно предположительно для 500k строк т.е. 500k раз сделать INDEX_RANGE_SCAN по табличке INST_INCREMENTAL. Более точно будет ясно если вы сюда скинете содержимое второй строчки блока PREDICATES в dbms_xplan. Но судя по всему это именно этот подзапрос:

Код: plsql

SELECT i.ISSUE_UBS_ID FROM INST_INCREMENTAL i WHERE i.ASSET_CLASS_SHORT = 'RDFUTR' AND i.ISSUE_UBS_ID=fu.ISSUE_UBS_ID

Почему столь высокий кост у INDEX_RANGE_SCAN? Посмотрите код индекса INST_INCREMENTAL_IDX. Или ведь должен существовать индекс у которого первое поле ISSUE_UBS_ID? Если нет - то создание такого индекса будет очевидным ответом. Если вы определите почему у него кост поиска по такому запросу 120k - вы вероятно решите проблему.
Кроме того, сам по себе FILTER с подзапросами - это почти всегда проблема. Исполнять сотни тысяч раз один подзапрос, пусть даже быстрый ( хотя в данном случае вероятно это не так ) - неээфективно. Подумайте, нельзя ли от него избавиться. Скажем переписать это на джойн с предварительно отфильтрованной порцией INST_INCREMENTAL.

Теперь: все сказанное выше имеет силу только при условии что у вас в базе все в порядке со статистикой и оценки оптимизатора имеют смысл. Я бы начал с проверки - на какой реально строчке у вас тормозит. Это можно проверить запустив запрос с хинтом MONITOR и наблюдая real-time-monitoring вьюхи. ( Судя по тому что у вас экзадата, и на diagnostics пак не должны были поскупиться ). Там вы увидите и время, и количество строк выполнения. Если время тратится действительно в блоке 14-16 строчки - вы знаете что делать.
Если нет возможности запустить сейчас, то вы можете определить это в истории ASH/AWR ( gv$active_session_history/ dba_hist ).
Там есть поле sql_plan_line_id.

...

Рейтинг:

0 / 0

12.11.2018, 18:03

| Ответить | Цитировать | Написать

Как еще можно оптимизировать запрос?

#39731980

Valergrad

Участник

Сообщения: 601

Рейтинг: 0 / 0

И да - отформатируете запрос CTRL+SHIFT+F или что там у вас, невозможно читать же.

...

Рейтинг:

0 / 0

12.11.2018, 18:06

| Ответить | Цитировать | Написать

Как еще можно оптимизировать запрос?

#39732013

-2-

Участник

Сообщения: 15 349

Рейтинг: 0 / 0

julat21Вариант 1. Есть множество 1, которое пересекается с множеством 2 по опеределенному полю. Результат по этому полю проверяется со множеством 3.

Вариант 2. Если изначально проверить множетсво 1 с множеством 3, потом 2 с множеством 3 и их подрезультат пересечь, то мы получим тот же результат, что в варианте 1.Во-первых. Не по "этому" полю, а по этому ИЛИ по другому. Если обрезать множества до соединения, то ИЛИть может быть уже нечего.
Во-вторых. Абстрагируясь от несовместимого результата, джоин, как правило, выполняется по ключу и не умножает количество строк. Проверять условие до джоина, это N+M проверок. После - не больше greatest(N, M). Вопрос лишь в том, что эффективнее выполнять вперед: джоин-иннер или джоин-экзистс.

...

Рейтинг:

0 / 0

12.11.2018, 18:55

| Ответить | Цитировать | Написать

Как еще можно оптимизировать запрос?

#39732029

julat21

Участник

Сообщения: 49

Рейтинг: 0 / 0

-2-,

Код: plsql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.

with  t1  as  (select 1 as idkey from dual
               union all
               select 1 as idkey from dual
               union all
               select 1 as idkey from dual
               ),
      t2  as  (select 1 as idkey from dual
               union all
               select 1 as idkey from dual
             )
       select * from t1  inner join t2 on t1.idkey = t2.idkey
       where func_rez(t1.id_key)>0

По Вашему утверждению представленый запрос выполнит функцию func_rez 3 раза?
Я думаю она выполниться все 6 раз для конечного множества. Поэтому предварительное использование фильтрации в данных вызовет функцию только 5 раз... ИМХО. Могу ошибаться...

...

Рейтинг:

0 / 0

12.11.2018, 19:22

| Ответить | Цитировать | Написать

Как еще можно оптимизировать запрос?

#39732044

Elic

Участник

Сообщения: 30 360

Рейтинг: 0 / 0

julat21Я думаю ... Могу ошибаться...Тут всё просто. Свою невесомую потенциально ошибочную мысль лучше всего подкреплять тест-кэйсом.
А если соблюдать надлежащий порядок, то ошибочная мысль просто не просочится на форум, будучи отфильтрованной убедительным самопримером.

...

Рейтинг:

0 / 0

12.11.2018, 20:22

| Ответить | Цитировать | Написать

Как еще можно оптимизировать запрос?

#39732223

julat21

Участник

Сообщения: 49

Рейтинг: 0 / 0

Elic, перед тем как писать, я специально заюзал функцию и она действительно вызывается 6 раз, потому как 6 строчек изолированы друг от друга и функция зависит от внешних условий. Простой пример, если в функцию передавать статический параметр и возвращать + текущее время(которое не стоит на месте). 6 запросов - 6 разных моментов времени, 6 разных результатов.

...

Рейтинг:

0 / 0

13.11.2018, 10:14

| Ответить | Цитировать | Написать

Как еще можно оптимизировать запрос?

#39732228

julat21

Участник

Сообщения: 49

Рейтинг: 0 / 0

Elic,
Если моя мысль и мои тесты ошибочны, чтоб не убеждать в обратном, проще показать пример. Готов учиться и совершенствоваться.

...

Рейтинг:

0 / 0

13.11.2018, 10:21

| Ответить | Цитировать | Написать

24 сообщений из 24, страница 1 из 1

Форумы / Oracle [игнор отключен] [закрыт для гостей] / Как еще можно оптимизировать запрос?

Читали тему (0):

Читали форум (0):

Пользователи онлайн (0):

start [/forum/topic.php?fid=52&msg=39729333&tid=1883199]:	0ms
get settings:	6ms
get forum list:	10ms
check forum access:	2ms
check topic access:	2ms
track hit:	156ms
get topic data:	6ms
get forum data:	2ms
get page messages:	36ms
get tp. blocked users:	1ms
others:	242ms

total:	463ms

	Необходимые cookie
	Cookie для сбора статистики
	Cookie для маркетинга и рекламы