Запрос с rownum стал медленным

У меня есть таблица table с 21 миллионным счетом, из которых 20 миллионов соответствуют критерию col1= 'text'. Затем я начал итеративно устанавливать значение col2 в значение, не равное NULL. После того, как я мутировал 10 миллионов записей, следующий запрос получил медленно, что было быстро в начале:Запрос с rownum стал медленным

SELECT T_PK 
    FROM (SELECT T_PK 
     FROM table 
     WHERE col1= 'text' AND col2 IS NULL 
     ORDER BY T_PK DESC) 
WHERE ROWNUM < 100;

я заметил, что как только я удалить DESC, весь порядок по п ORDER BY T_PK DESC или всему внешний запрос с условием WHERE ROWNUM < 100 он быстро снова (быстрый означает пару секунд, < 10 с).

План выполнения выглядит следующим образом: enter image description here

где выполняется полнотекстовый индекс убывания индекса сканирования на ПК таблицы. Помимо индекса на ПК, у меня есть индекс, определенный на col2.

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

источник

2015-03-25 René Winkler

Вы выбираете через commits, что означает, что вы читаете откат. Возможно, сообщите вашим администраторам баз данных, что вы пытаетесь сделать (в любом случае, возглавьте) и выполните одно заявление об обновлении – tbone

Теперь, когда данные в 'col2' выглядят очень разными, чем раньше, вы можете извлечь выгоду из сбора табличной статистики, используя' DBMS_STATS.GATHER_TABLE_STATS'. Вы также можете захотеть заново создать свой индекс на 'col2', чтобы разрешить поиск с помощью' NULL': 'DROP INDEX index_on_col2; CREATE INDEX index_on_col2 ON table (col2, '1'); ' –

Для этого запроса:

SELECT T_PK 
FROM (SELECT T_PK 
     FROM table 
     WHERE col1= 'text' AND col2 IS NULL 
     ORDER BY T_PK DESC 
    ) t 
WHERE ROWNUM < 100;

Оптимальный показатель table(col1, col2, t_pk).

Я думаю, что проблема в том, что оптимизатор имеет выбор из двух индексов - либо для предложения where (col1 и - возможно - col2) или один на t_pk. Если у вас есть один индекс, который обрабатывает оба предложения, производительность должна улучшиться.

Одна из причин того, что DESC может повлиять на то, где находятся совпадающие строки. Если все совпадающие строки находятся в первых 100 000 строках таблицы, тогда при заказе нисходящего запроса, прежде чем найти совпадение, запрос может выкинуть 20,9 миллиона строк.

источник

2015-03-25 19:45:17

Запрос с rownum стал медленным

ответ

Смежные вопросы