Полное сканирование таблицы (также известный как последовательное сканирование ) является сканирование производится на базе данных , где каждая строка из таблицы считывается в последовательном (последовательный) порядок и столбцы , с которыми сталкиваются проверяются на действительность состояния. [1] Полное сканирование таблицы [2] обычно является самым медленным методом сканирования таблицы из-за большого количества операций ввода-вывода, требуемых с диска, которые состоят из нескольких поисков, а также дорогостоящих передач с диска в память.
Обзор
В базе данных запрос, который не проиндексирован, приводит к полному сканированию таблицы, при котором база данных обрабатывает каждую запись таблицы, чтобы найти все записи, соответствующие заданным требованиям. Даже если запрос выберет только несколько строк из таблицы, будут проверены все строки во всей таблице. Обычно это приводит к неоптимальной производительности, но может быть приемлемым для очень маленьких таблиц или когда накладные расходы на поддержание индексов в актуальном состоянии высоки.
Когда оптимизатор рассматривает полное сканирование таблицы [3]
Самый важный фактор при выборе зависит от скорости. Это означает, что следует использовать полное сканирование таблицы, когда оно является самым быстрым и не может использовать другой путь доступа. Ниже приведены несколько примеров полного сканирования таблицы.
- Без индекса
Оптимизатор должен использовать полное сканирование таблицы, поскольку индекса не существует.
- Небольшое количество рядов
Стоимость полного сканирования таблицы меньше, чем сканирование диапазона индексов из-за небольшой таблицы.
- При обработке запроса SELECT COUNT (*) в столбце существовали значения NULL.
Запрос подсчитывает количество пустых столбцов в типичном индексе. Однако SELECT COUNT (*) не может подсчитать количество пустых столбцов.
- Запрос неселективный
Количество возвращаемых строк слишком велико и занимает почти 100% всей таблицы. Эти строки не выбираются.
- Статистика таблицы не обновляется
Количество строк в таблице больше, чем раньше, но статистика таблицы еще не обновлена. Оптимизатор не может правильно оценить, что использование индекса происходит быстрее.
- Таблица имеет высокую степень параллелизма
Высокая степень параллелизма таблицы искажает оптимизатор от истинного пути, потому что оптимизатор будет использовать полное сканирование таблицы.
- Подсказка по полному сканированию таблицы
Подсказка позволяет оптимизатору использовать полное сканирование таблицы.
Примеры
В первом примере показан оператор SQL, который возвращает имя каждого красного цвета фруктов в таблице. Если в таблице плодов нет индекса для столбца цвета, то механизм базы данных должен загрузить и изучить каждую строку в фруктах, чтобы сравнить цвет каждой строки с красным:
ВЫБЕРИТЕ имя ИЗ фруктов ГДЕ цвет = 'красный';
Во втором примере показан оператор SQL, который возвращает имена всех фруктов в таблице плодов. Поскольку этот оператор не имеет условия - нет предложения WHERE - механизм базы данных будет использовать сканирование таблицы для загрузки и возврата данных для этого запроса, даже если таблица фруктов имеет индекс в столбце имени, потому что доступ - т.е. сканирование - таблица напрямую быстрее, чем доступ к таблице через дополнительный уровень абстракции индекса:
ВЫБЕРИТЕ имя ИЗ фруктов
Третий пример - это контрпример, который почти наверняка заставит механизм sql использовать индекс вместо сканирования таблицы. В этом примере используется почти тот же запрос, что и в предыдущем, но добавлено предложение ORDER BY, чтобы возвращаемые имена располагались в алфавитном порядке. Предполагая, что таблица фруктов имеет индекс в столбце имени, ядро базы данных теперь будет использовать этот индекс для возврата имен по порядку, поскольку доступ к таблице через дополнительный уровень абстракции индекса дает преимущество возврата строк в запрошенном порядке. . Если бы механизм загрузил строки с помощью сканирования таблицы, ему пришлось бы выполнить дополнительную работу по сортировке возвращенных строк. В некоторых крайних случаях - например, статистика, поддерживаемая ядром базы данных, показывает, что таблица содержит очень небольшое количество строк - оптимизатор все же может решить использовать сканирование таблицы для этого типа запроса:
ВЫБЕРИТЕ имя ИЗ фруктов ЗАКАЗАТЬ ПО ИМЕНИ
Плюсы и минусы
Плюсы:
- Стоимость предсказуема, так как каждый раз системе базы данных необходимо сканировать всю таблицу строка за строкой.
- Когда таблица занимает менее 2 процентов от буфера блока базы данных, полное сканирование таблицы выполняется быстрее.
Минусы:
- Полное сканирование таблицы происходит, когда индекс отсутствует или индекс не используется SQL . И результат полного сканирования таблицы обычно медленнее, чем сканирование индексной таблицы. Ситуация такова: чем больше таблица, тем медленнее возвращаются данные.
- Ненужное сканирование всей таблицы приведет к огромному количеству ненужных операций ввода-вывода с нагрузкой на всю базу данных.
Смотрите также
Рекомендации
- ^ «Как избежать сканирования таблиц» . Oracle. 2011 г.
- ^ «Что быстрее: индексный доступ или сканирование таблицы?» . Microsoft TechNet. 2002 г.
- ^ «Пути доступа к оптимизатору» . Oracle. 2013.