|
ASA 11: как победитъ оптимизатор
|
|||
---|---|---|---|
#18+
Картина примерно следующая: таблица наполнена на порядка 3 мио. строк. Запрос возвращает всего 16 значений и при этом используемый план включает полный паралелный скан таблицы. По моему убеждению есть по крайней мере дще возможности улутшить план: 1) паралелный скан на индексе. (если размер записи в индексе < размера саписи в таблице) 2) параллелный упорядоченый поиск по индексу. Вопрос: поведение оптимизатора можно обьяснить или победить? create table t (a varchar(12) not null, b varchar(4) not null, c smallint not null, d1 timestamp not null, d2 timestamp not null, primary key (a,b,c,d1), unique (a,b,c,d2) ); select count(*) from t; --> 3M rows select a,b,c, max(d2) from t group by a,b,c; --> 16 rows. Full parallel table scan. What about index? ... |
|||
:
Нравится:
Не нравится:
|
|||
10.05.2012, 10:48 |
|
ASA 11: как победитъ оптимизатор
|
|||
---|---|---|---|
#18+
mikron, Если такие запросы идут на постоянной основе, то не лучше ли сделать materialized view? ... |
|||
:
Нравится:
Не нравится:
|
|||
10.05.2012, 11:46 |
|
ASA 11: как победитъ оптимизатор
|
|||
---|---|---|---|
#18+
Обычно нужен отдельный индекс по полю, по которому ограничивается выборка. В данном случае - d2. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.05.2012, 11:56 |
|
ASA 11: как победитъ оптимизатор
|
|||
---|---|---|---|
#18+
antandmikron, Если такие запросы идут на постоянной основе, то не лучше ли сделать materialized view? Накладные расходы будут слишком велики. Таблица дополняется / обновляется 5~10 раз в секунду. А запрос выполнятся примерно 6 раз в час. Тогда уже выгодней субоптималный запрос. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.05.2012, 12:17 |
|
ASA 11: как победитъ оптимизатор
|
|||
---|---|---|---|
#18+
SiemarglОбычно нужен отдельный индекс по полю, по которому ограничивается выборка. В данном случае - d2. Идею не понял. Обясните пожалуста на пальцах, как можно использовать индекс по Д2 для оптимизации выполнения моего запроса? База сечас не доступна, но проверю позже. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.05.2012, 12:22 |
|
ASA 11: как победитъ оптимизатор
|
|||
---|---|---|---|
#18+
mikron, materialized view можно обновлять и не немедленно. А накладные расходы как оценивали? ... |
|||
:
Нравится:
Не нравится:
|
|||
10.05.2012, 12:43 |
|
ASA 11: как победитъ оптимизатор
|
|||
---|---|---|---|
#18+
mikronКартина примерно следующая: таблица наполнена на порядка 3 мио. строк. Запрос возвращает всего 16 значений и при этом используемый план включает полный паралелный скан таблицы. Отключи параллелизм в сессии, погляди, что будет без него. Вообще, странно, что он включен -- если это не DSS, то его лучше вообще выключить и включать только при надобности -- он жрёт много ресурсов, а толку от него чаще 0. 2) тебе надо приводить ТОЧНЫЕ запросы в том виде, в котором они не работают. А не примерный их вид. Как и точное описание реальной таблицы. И соответственно полные планы запросов, а не их пересказ. 3) Где в этих запросах : select count(*) from t select a,b,c, max(d2) from t group by a,b,c; ты вообще предполагаешь использование индекса ? select count(*) from t может использовать индекс как структуру, в которой заранее известно число строк. Будут сканироваться листовые или предлистовые уровни индекса для подсчёта числа строк. Но не более. select a,b,c, max(d2) from t group by a,b,c; d1 timestamp not null, d2 timestamp not null, -- ты уверен, что это именно timestamp ? а не datetime ? как бы max(d2) в таком случае бессмысленно. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.05.2012, 13:02 |
|
ASA 11: как победитъ оптимизатор
|
|||
---|---|---|---|
#18+
antandmikron, materialized view можно обновлять и не немедленно. А накладные расходы как оценивали? Допустим обновляем сразу после изменения. Тогда нужно чтобы 10 * 60 * 5 * Т(рефреш) < Т(запрос). Не верю. Допустим обновляем перед запросом. Тогда Т(рефреш) + Т(запрос на представлении) < Т(запрос) Только не понятно, почему план обновления должен быть лутше плана запроса? Смею предположить что Т(рефреш) > Т(запрос) antandА накладные расходы как оценивали? опыт * ПИ / возраст^0.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
10.05.2012, 13:10 |
|
ASA 11: как победитъ оптимизатор
|
|||
---|---|---|---|
#18+
MasterZivОтключи параллелизм в сессии, погляди, что будет без него. Вообще, странно, что он включен -- если это не DSS, то его лучше вообще выключить и включать только при надобности -- он жрёт много ресурсов, а толку от него чаще 0. Ага, проверю. оптимизатор левел ставил на максимум - 15. MasterZivтебе надо приводить ТОЧНЫЕ запросы в том виде, в котором они не работают. А не примерный их вид. Как и точное описание реальной таблицы. И соответственно полные планы запросов, а не их пересказ. ты уверен, что это именно timestamp ? а не datetime ? Да, каюсь, не без греха :) Всё правда: и названия полей другие, и полей больше, и индексов. Но сути это не меняет. --> select count(*) from t Только что бы показать кол-во данных в таблице. Это не проблема. --> select a,b,c, max(d2) from t group by a,b,c; Вот здесь проблема. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.05.2012, 13:24 |
|
ASA 11: как победитъ оптимизатор
|
|||
---|---|---|---|
#18+
mikron, В твоих условиях всегда будет полное сканирование таблицы, я например, не вижу условий, по которым можно как-то задействовать индексы. Была давно похожая задача, так там я разбивал на 2-е фазы, одна запихивала данные с определенными сортировкой и ограничениями во временную таблицу, а вторая вынимала из нее нужные мне данные... ... |
|||
:
Нравится:
Не нравится:
|
|||
10.05.2012, 15:41 |
|
ASA 11: как победитъ оптимизатор
|
|||
---|---|---|---|
#18+
Sergey Orlovmikron, В твоих условиях всегда будет полное сканирование таблицы, я например, не вижу условий, по которым можно как-то задействовать индексы. Если убрать первые три поля из индекса и из групировки в запросе, то тогда можно использовать индекс для нахождения максимума. Почему нелзя задействовать индекс? Теоритичски это просто: Код: plaintext 1. 2. 3. 4. 5. 6. 7.
... |
|||
:
Нравится:
Не нравится:
|
|||
10.05.2012, 17:04 |
|
ASA 11: как победитъ оптимизатор
|
|||
---|---|---|---|
#18+
mikron, Так тогда запрос будет уже другой... ... |
|||
:
Нравится:
Не нравится:
|
|||
10.05.2012, 23:19 |
|
ASA 11: как победитъ оптимизатор
|
|||
---|---|---|---|
#18+
Sergey Orlovmikron, Так тогда запрос будет уже другой... Это всё понятно. я был уверен, неизвестно почему, что тот-же принцип поиска максимуа / минимума по индексу, может исползоватся оптимизатором и в данном случае. И если я не ошибаюсь, то оракл знает/использует такую стратегию исполения запроса. Пусть меня поправять, если я не прав. Ищё одна мысль по птимизации - вынести значения первых трёх полей в отделниё таблицу и связать её с данными. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.
... |
|||
:
Нравится:
Не нравится:
|
|||
11.05.2012, 11:26 |
|
ASA 11: как победитъ оптимизатор
|
|||
---|---|---|---|
#18+
mikronИ если я не ошибаюсь, то оракл знает/использует такую стратегию исполения запроса. Пусть меня поправять, если я не прав. Попровляю: оракл (10g) тоже не может предложить ничего лутшего, чем полный скан таблицы. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.05.2012, 16:39 |
|
ASA 11: как победитъ оптимизатор
|
|||
---|---|---|---|
#18+
Заинтересовался темой, и посмотрел некоторые базы данных: постгрес, МС Сиквел 2008, оракл. Вот что нащёл пока. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.05.2012, 18:55 |
|
ASA 11: как победитъ оптимизатор
|
|||
---|---|---|---|
#18+
Product Suggestion: Index Skip Key Processing Расследование Вашего случая ... |
|||
:
Нравится:
Не нравится:
|
|||
21.05.2012, 17:13 |
|
ASA 11: как победитъ оптимизатор
|
|||
---|---|---|---|
#18+
Марсель,спасибо за наводку. Брек Картер гуру и спаситель! ... |
|||
:
Нравится:
Не нравится:
|
|||
22.05.2012, 12:03 |
|
|
start [/forum/topic.php?fid=55&fpage=15&tid=2010131]: |
0ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
44ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
55ms |
get tp. blocked users: |
1ms |
others: | 15ms |
total: | 162ms |
0 / 0 |