Как я могу ускорить row_number в Oracle?
попробуй это. ;)
.parent-split-row { display: flex; }
5 ответов
ROW_NUMBER довольно неэффективен в Oracle .
Подробнее о производительности см. В статье в моем блоге:
Для вашего конкретного запроса я бы рекомендовал вам заменить его на ROWNUM и убедиться, что индекс используется:
SELECT *
FROM (
SELECT /*+ INDEX_ASC(t index_on_column) NOPARALLEL_INDEX(t index_on_column) */
t.*, ROWNUM AS rn
FROM table t
ORDER BY
column
)
WHERE rn >= :start
AND rownum <= :end - :start + 1
В этом запросе будет использоваться COUNT STOPKEY
. Также убедитесь, что вы Столбец не может быть обнуляем, или добавить условие ГДЕ НЕ НЕДЕЙСТВИТЕЛЕН .
В противном случае индекс не может быть использован для извлечения всех значений.
Обратите внимание, что вы не можете использовать ROWNUM BETWEEN: start и: end без подзапроса.
ROWNUM всегда назначается последним и проверяется последним, поэтому ROWNUM всегда идут в порядке без пробелов.
Если вы используете ROWNUM МЕЖДУ 10 и 20 , первая строка, удовлетворяющая всем остальным условиям, станет кандидатом на возвращение, временно назначенным с ROWNUM = 1 и не пройдя проверку ROWNUM МЕЖДУ 10 И 20 .
Тогда следующей строкой будет кандидат, назначенный с ROWNUM = 1 и с ошибкой и т. Д., Поэтому, наконец, строки не будут возвращены
Это нужно обойти, поместив ROWNUM в подзапрос.
Это нужно обойти, поместив ROWNUM в подзапрос.
Это нужно обойти, поместив ROWNUM в подзапрос.
Индексируется ли ваш столбец ORDER BY? Если нет, то это хорошее место для начала.
Отчасти проблема в том, насколько велик «старт» к конец «пролета и где они« живут ». Скажем, у вас есть миллион строк в таблице, и вы хотите строки с 567 890 по 567 900, и вам придется смириться с тем фактом, что потребуется пройти через всю таблицу, отсортировав почти все по идентификатору, и определите, какие строки попадают в этот диапазон. Короче говоря, это большая работа, поэтому оптимизатор дорого обходится.
Индекс также не очень помогает. Индекс дает порядок, но в лучшем случае дает вам место для начала, а затем вы продолжаете чтение до тех пор, пока не доберетесь до 567 900-й записи.
Если вы покажете своему конечному пользователю 10 элементов за раз, это может стоило бы на самом деле взять 100 лучших из БД, а затем приложение разбить эти 100 на десять частей.
Для меня это выглядит как запрос на разбиение на страницы.
Из этой статьи ASKTOM (примерно на 90% вниз по странице):
Кроме того, ваши запросы не совпадают, поэтому я не уверен, в чем заключается преимущество сравнения затрат одного на другое.
Потратьте больше времени на инструмент EXPLAIN PLAN. Если вы видите TABLE SCAN, вам нужно изменить свой запрос.
Ваш запрос не имеет смысла для меня. Запросы по ROWID, похоже, напрашиваются на неприятности. В этом запросе нет реляционной информации. Это реальный запрос, с которым у вас возникли проблемы, или пример, который вы составили для иллюстрации своей проблемы?