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

Растровые индексы

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

Каждое значение растрового индекса указывает на некоторый объект, который можно назвать списком битов со значениями да и нет . Этот список, в свою очередь, отображается на полный список строк таблицы, причем биты да отображаются на строки, в которых для индексированного столбца существует значение. На этих битовых строках и битовых строках других растровых индексов удобно выполнять операции AND и OR, комбинируя условия для нескольких растровых значений многих индексов. Существенным недостатком битовых строк является дороговизна поддержки их синхронизации с часто меняющимся содержимым таблиц, особенно если обновления производятся в середине таблицы. Растровые индексы хорошо работают для таблиц, содержимое которых только считывается и очень редко меняется, но, с другой стороны, большие таблицы не разрастаются, если не изменять их содержимое, а для небольших таблиц специальные индексы эффективного доступа к данным не требуются. Наилучшее применение такого индекса - это действительно информационное хранилище, для которого он и был разработан. Например, база данных хранилища, доступная только для чтения в течение дня и периодически, например по ночам или по выходным, проводящая обновление всех таблиц при помощи некоторой базы данных транзакций, таблицы в которой постоянно увеличиваются в размере.

Пути доступа для одной таблицы

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

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

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

Основной путь доступа к таблице - это полное сканирование таблицы, то есть чтение таблицы полностью без использования индекса. На рис. 2.4 иллюстрируется этот метод в приложении к типичной таблице в Oracle.

Считыввнив нескольких

блоков по 64 Кбайт

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

Так как будет считана вся таблица, Oracle понимает, что следует выполнять операции физического ввода-вывода частями, размер которых больше, чем блок - в этом случае считываться будет по 64 Кбайт за раз. В результате выполняется меньшее количество объемных физических считываний, что занимает меньше времени, чем множество небольших физических считываний тех же блоков. Не все поставщики баз данных следуют этому методу, однако выясняется, что этим они достигают немногого, так как дисковые подсистемы и операционные системы обычно считывают сегменты большого размера, даже если база данных запрашивает один блок. База данных может выдать много запросов на считывание небольших объемов данных, но они преобразуются на низших системных уровнях в несколько запросов объемных операций считывания, а требование небольших запросов удовлетворяется за счет кэша дисковой подсистемы. Данные считываются с первого блока до отметки заполнения, вгшючая все встречающиеся пустые блоки. В случае, когда каждый из набора 64-килобайтовых блоков уже находится в кэше, кэширование позволяет базе данных избежать операции физического считывания нескольких блоков. База данных считывает блоки небольших и средних по размеру таблиц в кэш обычным образом, и они удаляются оттуда через несколько минут, если никакой другой запрос не обратится к ним. Кэширование небольших и средних таблиц целиком часто бывает полезным, и такие таблицы остаются в кэше надолго, если базе данных приходится часто сканировать их полностью.

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

Индексный доступ к таблицам

Самые важные затраты при полном сканировании таблицы приходятся на процессор: это стоимость изучения каждого блока под отметкой заполнения и стоимость изучения каждой строки в этих блоках.

Если только вы не считываете крохотную таблицу (а в этом случае любой метод доступа работает идеально) или большой фрагмент более объемной таблицы, следует убедиться, что ваши запросы обращаются к требуемым строкам при помощи индекса. На рис. 2.5 иллюстрируется индексный метод доступа к таблице.

Корень

Ветвь в

Листовой 6лок1

Идентификатор строки

Рис. 2.5. Индексный доступ к таблице

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