|
06.11.2002, 10:26
#32065237
Ссылка:
Ссылка на сообщение:
Ссылка с названием темы:
Ссылка на профиль пользователя:
|
|
|
Участник
Откуда: from Russia
Сообщения: 5 924
Рейтинг:
0
/ 0
|
|
|
|
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.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
Вопрос: Почему мой запрос работает медленно?
----------------------------------------------
Для того что бы понять что является причиной медленной работы запроса, можно пойти
методом от обратного, т.е. необходимо уяснить, какие условия и принципы заставляют запрос работать быстро?
И видимо несоблюдение данных принципов и условий и приводят к медленной работе запроса.
В данном случае не рассматривается общая производительность СУБД Oracle. Будем исходить из того,
что общая производительность настроена оптимально. Уже существуют разработанные запросы, которые работают
быстро.
Одним из распространённых и классических способов увеличения производительности запросов, являетс
использование индексов.
В отсутствие индекса, план выполнения запроса будет использовать полное сканирование таблицы (FULL SCAN),
что при использовании метода оптимизации на основе правил хуже чем поиск по индексу. Исходя из этого
определим причины по которым запрос работает медленно:
1 .Не был создан индекс.
Необходимо создать его.
2 .Индекс был создан когда-то, но в последствии был случайно удалён.
Необходимо проверить существование индекса и в случае его отсутствия создать его.
3 .Индекс был создан, он существует, но при выполнении не задействуется планом выполнения запроса.
Причин по которым индекс не используется, может быть несколько. Вот несколько из них:
a) в условии запроса не указаны столбцы, которые были включены в индекс.
Необходимо включить в запрос столбцы, указанные в индексе или создать индекс, который включает
в себя столбцы, которые участвуют в условии запроса;
b) для составного ключа, столбцы участвующие в запросе соединены не оператором AND, а скажем
оператором OR. В этом случае составной индекс не будет задействован в плане выполнения;
c)в случае использования столбца в условии, которое определяет ограниченные интервал ,
т.е. при использовании операторов ">[=], <[=], LIKE, BETWEEN" , столбец в составном индексе не
вляется ведущим;
d) при использовании указателей (хинтов), указывающих на использование индекса,
таких как INDEX, INDEX_ASC, INDEX_DESC, была допущена ошибка. Например, неправильно указано
имя таблицы или индекса. Или хинт в целом написан неправильно;
В случае же использования оптимизации на основе издержек(стоимостной оптимизатор), даже если с точки
зрения оптимизации на основе правил индекс должен использоваться - использование индекса уже не
гарантируется. В определённых условиях оптимизатор может посчитать, что стоимость полного сканировани
таблицы меньше и не будет использовать индекс. Если же вы считаете, что при использовании оптимизации
на основе издержек, определённый запрос, должен всегда использовать оптимизацию на основе правил,
необходимо в запросе указать хинт RULE.
4 .Индекс существует, но был неправильно указан порядок столбцов, поэтому использование индекса
неэффективно. В индексе столбцы необходимо указывать в порядке уменьшения числа неповторяемости
значений столбца.
Рассмотрим другие причины медленной работы запроса, не связанные с использованием индексов:
1 .В запросе используются несколько таблиц, но не указано условие соединения или указано неверно.
В этом случае каждая строка одной таблицы будет соединена с каждой строкой другой таблицы.
Это может привести к очень длительному выполнению запроса, особенно при большом количестве записей
в таблицах
2 . Запрос просто возвращает очень много записей.
Попробуйте ограничить количество возвращаемых записей дополнительными условиями. Также можно
использовать псевдостолбец ROWNUM, который в результирующем наборе данных возвращает номер каждой
строки. Необходимо включить его в условие так:
SELECT * FROM user_tables WHERE ROWNUM< 10 ;
Запрос вернёт только менее 10 строк.
3 . В запросе указано, слишком много столбцов. Попробуйте изменить символ "*" на конкретный список
столбцов, который вам необходим.
4 . В запросе много вложенных циклов. Необходимо проанализировать запрос и переписать его с уменьшением
числа вложенных циклов.
5 . У вас несколько баз данных на разных серверах и количество записей таблиц существенно отличается.
Вы ошибочно подключились не к той базе,
которой хотели и ожидаемое время выполнения запроса показалось вам не оправдано большим.
Здесь были перечислены не все возможности увеличения производительности запроса, такие как
использование кластеров, секционирование. Следовательно не были рассмотрены и причины, связанные
с их использованием(или не использованием), по которым ваш запрос может работать медленно.
Но часто бывает что разработчики SQL-запросов не имеют возможности изменять физическую структуру
данных и им приходиться довольствоваться тем что есть. Поэтому для первоначального анализа медленной
работы запроса, выше перчисленных причин вполне достаточно.
|
|
|
