Концепция Ровида:
rowid — это псевдостолбец. Поскольку это псевдостолбец, этот столбец не определяется пользователем, а добавляется самой системой. Для каждой таблицы существует псевдостолбец rowid, но значение столбца ROWID физически не хранится в таблице. Однако вы можете использовать его, как и любой другой столбец, но вы не можете удалить или изменить столбец, а также не можете изменить или вставить значение столбца. После того как строка данных вставлена в базу данных, идентификатор строки уникален в течение жизненного цикла строки, то есть даже если строка подвергается миграции, идентификатор строки не изменится.
Зачем использовать ROWID
rowid обеспечивает самый быстрый метод доступа к данной строке таблицы. Соответствующий блок данных можно найти непосредственно через ROWID, а затем прочитать в память. Когда мы создаем индекс, индекс не только сохраняет значение столбца индекса, но также сохраняет ROWID строки, соответствующей значению индекса. Таким образом, после того, как мы быстро найдем ROWID соответствующей строки через индекс, мы можем быстро запросить данные через ROWID. Вот почему использование индексных запросов происходит быстрее.
В предыдущих версиях ORACLE8 ROWID состоял из ФАЙЛА, БЛОКА и НОМЕРА СТРОКИ. С расширением концепции объекта в Oracle8 ROWID изменился и состоит из ОБЪЕКТА, ФАЙЛА, БЛОКА и НОМЕРА СТРОКИ. Вы можете использовать DBMS_ROWID для разложения идентификатора строки на указанные выше части или объединить указанные выше части в действительный идентификатор строки.
Концепция рекурсивного SQL Иногда для выполнения оператора sql, выданного пользователем, Oracle должен выполнить некоторые дополнительные операторы. Мы называем эти дополнительные операторы «рекурсивными вызовами» или «рекурсивными операторами SQL». Например, когда выдается инструкция DDL, ORACLE всегда неявно выдает некоторые рекурсивные инструкции SQL для изменения информации словаря данных, чтобы пользователь мог успешно выполнить инструкцию DDL. Рекурсивные вызовы часто происходят, когда необходимая информация словаря данных не находится в общей памяти. Эти рекурсивные вызовы считывают информацию словаря данных с жесткого диска в память. Пользователей не волнует выполнение этих рекурсивных операторов SQL. ORACLE автоматически выполняет эти операторы внутри себя, когда это необходимо. Конечно, и операторы DML, и SELECT могут вызывать рекурсивный SQL. Проще говоря, мы можем думать о триггерах как о рекурсивном SQL.
Источник строки
При использовании в запросах набор уточняющих строк, возвращаемых предыдущей операцией, может быть набором всех данных строк в таблице, а также набором данных частичных строк в таблице или набором из двух вышеупомянутых; Источники строк. Коллекция данных строк, полученных после операции соединения (например, соединения соединения).
Предикат
Ограничения WHERE в запросе
Стол для вождения
Эту таблицу еще называют внешней таблицей (OUTER TABLE). Эта концепция используется во вложенных и HASH-соединениях. Если источник строк возвращает больше данных строк, это окажет негативное влияние на все последующие операции. Обратите внимание: хотя это переводится как управляющая таблица, на самом деле это более точно переводится как управляющий источник строк. Вообще говоря, после применения ограничений запроса таблица с меньшим количеством источников строк возвращается в качестве управляющей таблицы. Поэтому, если большая таблица имеет ограничения (например, ограничения равенства) в условии WHERE, большая таблица также будет использоваться в качестве управляющей. table Подходит, поэтому дело не в том, что в качестве управляющих таблиц можно использовать только таблицы меньшего размера. Правильным утверждением должно быть то, что после применения ограничений запроса в качестве управляющей таблицы используется таблица, которая возвращает меньшее количество источников строк. В плане выполнения это должен быть источник верхней строки. Конкретные инструкции будут даны позже. В нашем последующем описании эта таблица обычно упоминается как источник строк 1 операции соединения.
Зондирующий стол (зондирующий стол)
Эту таблицу еще называют внутренней таблицей (INNER TABLE). После того, как мы получили определенную строку данных из таблицы драйверов, мы ищем в таблице строки, соответствующие условиям соединения. Таким образом, таблица должна быть большой (на самом деле это должна быть таблица, которая возвращает больший источник строк), и в соответствующих столбцах должны быть индексы. В нашем последующем описании эта таблица обычно упоминается как источник строк 2 операции соединения.
комбинированный индекс (составной индекс)
Индекс, состоящий из нескольких столбцов, например, create index idx_emp on emp(col1, col2, col3,...), тогда мы называем индекс idx_emp составным индексом. В комбинированном индексе есть важная концепция: ведущий столбец. В приведенном выше примере столбец col1 является ведущим столбцом. Когда мы делаем запрос, мы можем использовать «where col1 = ?» или «where col1 = ? и col2 = ?». Такие ограничения будут использовать индекс, но запрос «where col2 =?» не будет использовать индекс. Таким образом, только если ведущий столбец включен в ограничение, для ограничения будет использоваться объединенный индекс.
Селективность:
Сравнение количества уникальных ключей в столбце с количеством строк в таблице определяет избирательность столбца. Если соотношение «количество уникальных ключей/количество строк в таблице» столбца ближе к 1, избирательность столбца выше, столбец больше подходит для создания индекса, а избирательность индекса также выше. При запросе по столбцам с широкими возможностями выбора будет возвращено меньше данных, поэтому индексные запросы более подходят.
Имея эти базовые знания, мы начинаем знакомить с планом выполнения. Чтобы выполнить оператор, Oracle, возможно, придется выполнить множество шагов. Каждый из этих шагов может заключаться в физическом извлечении строк данных из базы данных или их подготовке каким-либо образом для использования пользователем, выдающим оператор. Комбинация этих шагов, которые Oracle использует для выполнения оператора, называется планом выполнения. План выполнения — самая сложная и важная часть оптимизации SQL. Только зная, как ORACLE выполняет оператор SQL внутри себя, мы можем узнать, является ли план выполнения, выбранный оптимизатором, оптимальным. Планы выполнения так же важны для администраторов баз данных, как финансовые отчеты для финансового персонала. Итак, основные проблемы, с которыми мы сталкиваемся: как получить план выполнения; как проанализировать план выполнения, чтобы выявить основные проблемы, влияющие на производительность. Далее мы начнем с анализа плана выполнения дерева, затем покажем, как получить план выполнения, а затем расскажем, как анализировать план выполнения.
Пример:
В этом примере показан план выполнения следующего оператора SQL.
ВЫБЕРИТЕ ename, job, sal, dname
ОТ emp, отдел
ГДЕ emp.deptno = derpt.deptno
И НЕ СУЩЕСТВУЕТ
(ВЫБИРАТЬ *
ИЗ Салграда
ГДЕ emp.sal МЕЖДУ losal И hisal );
Этот оператор запрашивает имя, должность, зарплату и название отдела всех сотрудников, чья зарплата не попадает ни в один из рекомендуемых диапазонов зарплат.
Эта статья взята из блога CSDN. При перепечатке указывайте источник: http://blog.csdn.net/lcyhjx/archive/2009/12/20/5044672.aspx.