Оптимизатор SQL для большой таблицы БД

Question

У меня есть таблица с миллионами строк, которые мне нужно объединить, чтобы делать выборки. время отклика не так хорошо, как я могу улучшить его ответ? я попытался добавить индекс в столбцы, по которым я выбираю, есть ли инструмент, который я могу использовать для оптимизации SQL или как я могу диагностировать узкие места SQL и улучшить его? Любое предложение будет очень оценено. Я использую сервер Oracle 10g и asp.net в качестве моего клиента. Есть ли какой-либо другой вид индексирования, полезный для таблиц с миллионами строк?

Answer 1

Возможно, вам следует начать с ОБЪЯСНИТЬ ПЛАН .

Используйте инструкцию EXPLAIN PLAN, чтобы определить план выполнения Oracle База данных следует для выполнения указанного оператора SQL. Это утверждение вставляет строку, описывающую каждый шаг плана выполнения в указанная таблица. Вы также можете выполнить оператор EXPLAIN PLAN как часть средства трассировки SQL.

Это заявление также определяет стоимость выполнения заявления. Если любые доменные индексы определены в таблице, затем пользовательский процессор и Затраты на ввод / вывод также будут включены.

Затем отредактируйте свой вопрос и опубликуйте оператор SQL и вывод EXPLAIN PLAN.

Позже. , .

Я не собираюсь вам сильно помогать в этом вопросе. 269 ​​строк, не менее 29 команд SELECT, параллельных запросов, удаленных баз данных, внешних объединений (в старом стиле) и т. Д.

Лучший совет, который я могу вам дать, -

• получить больше информации из EXPLAIN PLAN и
• упростить задачу.

Таблица плана содержит больше столбцов, чем обычно публикуется. Столбцы COST, CARDINALITY, BYTES и TIME могут быть полезны для определения приоритетов при настройке.

У вас есть 10 полных сканирований таблицы в этом запросе. («TABLE ACCESS FULL» в плане запроса.) Обычно это плохой знак; полное сканирование таблицы часто занимает относительно много времени. Это не всегда плохой знак. Полное сканирование крошечной таблицы может быть быстрее сканирования индекса.

Начните с получения выходных данных EXPLAIN PLAN для каждого из 29 операторов SELECT в вашем запросе. Если у любого из них будет полное сканирование таблицы, вы, вероятно, сможете улучшить их производительность с помощью подходящих индексов . (Oracle поддерживает множество различных типов индексов. Не забывайте о возможностях многоколоночных индексов.) В любом случае вывод EXPLAIN PLAN поможет вам определить самый медленный из 29 SELECT.

Answer 2

С этим запросом и планом могут возникнуть тысячи проблем, и вам может помочь только местный эксперт.

Но что бы это ни стоило, первое, что я заметил, это то, что только 1/5 вашего плана использует параллелизм. Обычно вы хотите, чтобы все шаги выполнялись параллельно или ни один из них не выполнялся параллельно.

Если ваш запрос возвращает только небольшой объем данных, возможно, издержки параллелизма не стоят этого. Oracle может потребоваться несколько дополнительных секунд, чтобы настроить параллельные процессы, координировать их и выполнить дополнительные шаги для оптимизации плана (например, увеличить динамическую выборку). Считывание индекса серии, вероятно, будет работать намного лучше, чем параллельное полное сканирование таблицы. Вам может потребоваться изменить СТЕПЕНЬ таблицы или использовать подсказку NOPARALLEL.

Если ваш запрос возвращает большой объем данных, вы, вероятно, захотите использовать как можно больше параллельных хеш-соединений, чтобы эффективно объединить все. Для действительно больших запросов худшая производительность обычно возникает, когда Oracle недооценивает мощность и использует вложенные циклы и индексы. Посмотрите на свою мощность и найдите первую часть в плане, где оценка значительно ниже фактической, что приблизит вас к проблеме.