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

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

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

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

Я привожу в этой главе все подробности по двум причинам.

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

Людям, которые занимаются настройкой запросов, часто задают неловкие вопросы, например: Почему этот запрос, возвращая 200 строк, работает в 12 раз дольше, чем другой, который возвращает 1000 строк? Другой распространенный вопрос: Не лучше ли было бы для ускорения выполнения запроса ж-иолъъоъатъ<Вставъте с(шый модный гпип объектов этого года>1 Толшо глубокое понимание основ, обсуждаемых в этой главе, поможет ответить на подобные вопросы.

Я немного забегу вперед. Многие особенности в этой главе упомянуты из-за сложной природы Oracle. Я обнаружил, что максимально точные описания помогают получать верные интуитивные догадки о правильных способах выполнения запросов и настройки базы данных, так как вы можете держать в голове подробную, точную картину происходящего. Я мог бы выбрать и другую базу данных для описания форматов таблиц, методов соединения и доступа к таблицам, но ни одно решение не может угодить всем. Оказывается, в большинстве случаев различия между серверами баз данных не влияют на настройку SQL. Лишь в редких случаях имеет значение конкретная реализация определенного поставщика, и в таких случаях я подробно описываю различия.

Кэширование в базе данных

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

Буфер блоков

Головв совместно используемого кэша Хвост

Физический ввод-вывод

Приблизительно 100000 блоков не поквзвны

Диск

Мусор

Рис. 2.1. Кэширование данных

Длинный растянутый по горизонтали серый прямоугольник (который был бы действительно длинным, если бы включал 100 ООО блоков, изъятых из середины) представляет большой сегмент памяти, одновременно доступный всем сеансам базы данных. Этот сегмент памяти, известный как буфер блоков кэша, состоит из одинаковых по размеру (обычно 2-16 Кбайт в зависимости от конфигурации базы данных) блоков данных, скопированных с диска. В этих блоках хранятся данные, недавно полученные из таблиц и индексов баз данных. Узкие серые прямоугольники представляют отдельные блоки.

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