Информационный сайт

 

Реклама
bulletinsite.net -> Книги на сайте -> Программисту -> Тоу Д. -> "Настройка SQL. Для профессионалов" -> 23

Настройка SQL. Для профессионалов - Тоу Д.

Тоу Д. Настройка SQL. Для профессионалов — СПб.: Питер, 2004. — 333 c.
ISBN 5-94723-959-0
Скачать (прямая ссылка): nastroykasqldlyaprof2004.djvu
Предыдущая << 1 .. 17 18 19 20 21 22 < 23 > 24 25 26 27 28 29 .. 161 >> Следующая


Выбор между полным сканированием таблицы и индексным доступом

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

¦ Индексные считывания практически всегда кэшируются.

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

¦ У одного блока вероятность попасть в кэш больше, чем у группы из нескольких блоков, поэтому эффективный коэффициент попадания в кэш для таблицы лучше при индексном считывании. Например, если в кэше находится половина блоков таблицы, выбранная случайным образом, то коэффициент попадания в кэш при чтении одного блока из этой таблицы равен 50 %, а вероятность нахождения в кэше всех восьми блоков при считывании нескольких блоков равна всего лишь 0,58, то есть приблизительно 0,4 %. Чтобы достигнуть эффективного коэффициента попадания в кэш не менее 50 % для считывания восьми блоков, необходимо достигнуть коэффициента попадания в кэш, равного 91,7 %, для отдельных блоков, кэшированных случайным образом.

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

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

1 Я не пытаюсь зря потратить ваше время на незначительный пример. Различия будут иметь значение,

если расширить этот пример до весьма объемных таблиц и индексов, но такой пример невозможно

проиллюстрировать так же подробно, как на рис. 2.6. При помощи этого небольшого примера я зна-

комлю вас с общими принципами.
48

2. Основы доступа к данным

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

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

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

¦ <0,5 % строк Индексный доступ.

¦ 0,5 %-20 %

Необходимо рассмотреть дополнительные условия.

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

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

¦ Запрос обращается к строкам, которые достаточно горячи, обеспечивая лучшее кэширование в индексированном диапазоне, чем будет выполнено при полном сканировании таблицы.

¦ Запрос считывает только одно значение, обращаясь к строкам по порядку в зависимости от их идентификаторов. Если у вас есть условия точного равенства по полностью индексированному ключу, то, считывая идентификаторы строк для этого единственного ключевого значения, сканирование индекса возвращает их в отсортированном порядке. Если сервер баз данных требует физического ввода-вывода, то в этом случае доступ выполняется практически аналогично полному сканированию таблицы, когда считывающая головка плавно движется от начала до конца диапазона. Поскольку расположенные рядом строки считываются последовательно, чаще всего самокэширование успешно происходит как в кэше сервера, так и в кэше дисковой подсистемы ввода-вывода, которая выполняет опережающее считывание.
Предыдущая << 1 .. 17 18 19 20 21 22 < 23 > 24 25 26 27 28 29 .. 161 >> Следующая
Реклама
Авторские права © 2009 AdsNet. Все права защищены.
Rambler's Top100