Полное сканирование таблицы

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

Обзор

запрос В базе данных неиндексированный приводит к полному сканированию таблицы, при котором база данных обрабатывает каждую запись таблицы, чтобы найти все записи, соответствующие заданным требованиям. Даже если запрос выберет всего несколько строк из таблицы, будут проверены все строки во всей таблице. Обычно это приводит к неоптимальной производительности, но может быть приемлемым для очень маленьких таблиц или когда накладные расходы на поддержание актуальности индексов высоки.

Когда оптимизатор рассматривает возможность полного сканирования таблицы

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

• Индекс отсутствует. Оптимизатор должен использовать полное сканирование таблицы, поскольку индекса не существует.
• Небольшое количество строк. Из-за небольшого размера таблицы стоимость полного сканирования таблицы меньше, чем сканирования диапазона индекса.
• При обработке запроса SELECT COUNT(*) в столбце присутствовали значения NULL. Запрос подсчитывает количество столбцов NULL в типичном индексе. Однако SELECT COUNT(*) не может подсчитать количество пустых столбцов.
• Запрос неселективный. Число возвращаемых строк слишком велико и занимает почти 100% всей таблицы. Эти строки не являются выборочными.
• Статистика таблицы не обновляется. Количество строк в таблице больше, чем раньше, но статистика таблицы еще не обновлена. Оптимизатор не может правильно оценить, что использование индекса происходит быстрее.
• Таблица имеет высокую степень параллелизма. Высокая степень параллелизма таблицы сбивает оптимизатор с истинного пути, поскольку оптимизатор будет использовать полное сканирование таблицы.
• Подсказка по полному сканированию таблицы. Подсказка позволяет оптимизатору использовать полное сканирование таблицы.

Примеры

В первом примере показан оператор SQL , который возвращает название каждого фрукта в таблице фруктов, имеющего красный цвет. Если в таблице фруктов нет индекса для столбца цвета, то механизм базы данных должен загрузить и проверить каждую строку внутри фруктов, чтобы сравнить цвет каждой строки с «красным»:

SELECT   name
FROM     fruits
WHERE    color = 'red';

Во втором примере показан оператор SQL, который возвращает названия всех фруктов в таблице фруктов. Поскольку в этом операторе нет условия (нет предложения WHERE), ядро ​​базы данных будет использовать сканирование таблицы для загрузки и возврата данных для этого запроса, даже если таблица фруктов имеет индекс в столбце имени, поскольку доступ, т. е. сканирование, непосредственно к таблице быстрее, чем доступ к таблице через дополнительный уровень абстракции индекса:

SELECT   name
FROM     fruits

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

SELECT   name
FROM     fruits
ORDER BY name

Плюсы и минусы

Плюсы:

• Стоимость предсказуема, поскольку каждый раз системе базы данных необходимо сканировать всю таблицу построчно.
• Если таблица занимает менее 2 процентов буфера блоков базы данных, полное сканирование таблицы происходит быстрее.

Минусы:

• Полное сканирование таблицы происходит, когда индекс отсутствует или индекс не используется SQL . И результат полного сканирования таблицы обычно медленнее, чем сканирование индексной таблицы. Ситуация такова: чем больше таблица, тем медленнее возвращаются данные.
• Ненужное полное сканирование таблицы приведет к огромному количеству ненужных операций ввода- вывода с нагрузкой на всю базу данных.

См. также

• База данных
• Индекс базы данных
• Оптимизирующий компилятор
• План запроса
• Оптимизация запросов
• SQL

Внешние ссылки

• Советы по полному сканированию таблиц Oracle