Полное сканирование таблицы - Full table scan

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

Обзор

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

Когда оптимизатор рассматривает полное сканирование таблицы[3]

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

  • Без индекса

Оптимизатор должен использовать полное сканирование таблицы, поскольку индекса не существует.

  • Небольшое количество рядов

Стоимость полного сканирования таблицы меньше, чем сканирование диапазона индексов из-за небольшой таблицы.

  • Когда запрос обработал SELECT COUNT (*), в столбце существовали нули

Запрос подсчитывает количество пустых столбцов в типичном индексе. Однако SELECT COUNT (*) не может подсчитать количество пустых столбцов.

  • Запрос неселективный

Количество возвращаемых строк слишком велико и занимает почти 100% всей таблицы. Эти строки не выбираются.

  • Статистика таблицы не обновляется

Количество строк в таблице больше, чем раньше, но статистика таблицы еще не обновлена. Оптимизатор не может правильно оценить, что использование индекса происходит быстрее.

  • Таблица имеет высокую степень параллелизма

Высокая степень параллелизма таблицы искажает оптимизатор в истинном свете, потому что оптимизатор будет использовать полное сканирование таблицы.

  • Подсказка по полному сканированию таблицы

Подсказка позволяет оптимизатору использовать полное сканирование таблицы.

Примеры

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

   ВЫБЕРИТЕ имя ИЗ фруктов, ГДЕ цвет = 'красный';

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

   ВЫБЕРИТЕ имя ИЗ фруктов

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

   ВЫБРАТЬ имя ИЗ фруктов ЗАКАЗАТЬ ПО имени

За и против

Плюсы:

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

Минусы:

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

Смотрите также

Рекомендации

  1. ^ «Избегание сканирования таблиц». Oracle. 2011 г.
  2. ^ «Что быстрее: индексный доступ или сканирование таблицы?». Microsoft TechNet. 2002 г.
  3. ^ «Пути доступа к оптимизатору». Oracle. 2013.