Чтение страниц данных в ядре СУБД

применимо к:SQL ServerУправляемому экземпляру SQL Azure

Операции ввода-вывода из экземпляра подсистемы базы данных SQL Server включают логическое и физическое чтение. Логическое чтение происходит каждый раз, когда ядро СУБД запрашивает страницу из буферного кэша, также известного как буферный пул. Если страница в настоящее время не находится в буферном кэше, физическое чтение сначала копирует страницу с диска в кэш.

Запросы на чтение, созданные экземпляром ядра СУБД, управляются реляционным ядром и оптимизированы подсистемой хранилища. Реляционный механизм определяет наиболее эффективный метод доступа (например, сканирование таблицы, сканирование индекса или чтение с ключом). Методы доступа и компоненты диспетчера буферов подсистемы хранилища определяют общий шаблон операций чтения и оптимизируют операции чтения, необходимые для реализации метода доступа. Поток, выполняющий пакетную обработку, планирует выполнение операций считывания.

Предварительное чтение

Ядро СУБД поддерживает механизм оптимизации производительности, называемый чтением вперед. Предварительное чтение предвосхищает страницы данных и индексов, необходимые для выполнения плана запроса, и загружает их в кэш буфера до их использования запросом. Этот процесс позволяет вычислениям и операциям ввода-вывода перекрываться, используя все преимущества ЦП и диска.

Механизм предварительного чтения позволяет СУБД считывать до 64 смежных страниц (512 КБ) из одного файла. Чтение выполняется как единое scatter-gather чтение в нужное количество (вероятно, неконтинуальных) буферов в кэше буферов. Если какая-либо из страниц в диапазоне уже находится в буферном кэше, соответствующая страница, прочитанная из этого диапазона, удаляется после завершения чтения. Диапазон страниц также может быть "обрезан" с любого конца, если соответствующие страницы уже присутствуют в кэше.

Выделяются два типа упреждающего чтения: один для страниц данных и один для индексных страниц.

Чтение страниц данных

Проверки таблиц, используемые ядром СУБД для чтения страниц данных, эффективны. Страницы карты распределения индекса (IAM) в базе данных SQL Server содержат указатели на экстенты, используемые таблицей или индексом. Подсистема хранилища может считывать IAM для построения отсортированного списка адресов на диске, которые необходимо считать. Это позволяет подсистеме хранения оптимизировать операции ввода-вывода, выполняемые в виде крупных последовательных операций чтения, основанных на их расположении на диске. Дополнительные сведения о страницах IAM см. в разделе "Управление пространством, используемым объектами".

Читать страницы индекса

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

Подсистема хранения использует информацию из промежуточной страницы индекса, расположенной выше уровня листьев, для организации последовательного упреждающего чтения страниц, содержащих ключи. Если запрос выполняется для всех ключей от ABC до DEF, система хранения сначала считывает страницу индекса над листовой страницей. Однако она не просто считывает каждую страницу данных в последовательности со страницы 504 на страницу 556 (последняя страница с ключами в указанном диапазоне). Вместо этого движок хранения просматривает промежуточную страницу индекса и строит список страниц-листьев для считывания. Затем подсистема хранилища планирует все операции ввода-вывода в порядке следования ключей. Кроме того, подсистема хранилища определяет, что страницы 504/505 и 527/528 являются смежными, и выполняет одноразовое чтение с разбросом, чтобы за одну операцию получить данные с этих смежных страниц. Если в последовательной операции необходимо получить много страниц, хранилище данных планирует выполнение блока операций чтения одновременно. После завершения подмножества этих операций чтения подсистема хранилища планирует равное количество новых операций чтения до тех пор, пока не будут запланированы все необходимые операции чтения.

Подсистема хранилища использует предварительную выборку для ускорения поиска базовой таблицы из некластеризованных индексов. Конечные строки в некластеризованном индексе содержат указатели на строки данных, в которых хранятся все определенные значения ключей. Так как подсистема хранилища считывает конечные страницы некластеризованного индекса, она также начинает планирование асинхронных операций чтения для строк данных, указатели которых уже получены. Это позволяет обработчику хранилища извлекать строки данных из базовой таблицы до завершения сканирования некластеризованного индекса. Этот процесс выполняется независимо от наличия в таблице кластеризованного индекса. Выпуск SQL Server Enterprise использует более предварительную выборку, чем другие выпуски SQL Server, что позволяет читать дополнительные страницы заранее. Уровень предварительной выборки не настраивается ни в одном выпуске. Дополнительные сведения о некластеризованных индексах см. в разделе Кластеризованные и некластеризованные индексы.

Расширенная проверка

В выпуске SQL Server Enterprise функция расширенного сканирования позволяет нескольким задачам совместно использовать полные проверки таблиц. Если для плана выполнения инструкции Transact-SQL требуется сканирование страниц данных в таблице, а ядро СУБД обнаруживает, что таблица уже сканируется для другого плана выполнения, ядро СУБД присоединяет вторую проверку к первой, в текущем расположении второго сканирования. Ядро СУБД считывает каждую страницу по одному разу и передает строки из каждой страницы в оба плана выполнения. Это продолжается до тех пор, пока не будет достигнут конец таблицы.

На этом этапе первый план выполнения имеет полные результаты сканирования. Однако второй план выполнения по-прежнему должен получить ранее прочитанные страницы данных, прежде чем присоединится к выполняющемуся сканированию. Затем сканирование для второго плана выполнения возвращается к первой странице данных таблицы и продолжается вперёд до точки, где оно соединяется с первым сканированием. Таким образом, можно объединять любое количество сканов. Ядро СУБД продолжает выполнять циклы по страницам данных до тех пор, пока не завершится все проверки. Этот механизм также называется "сканированием по кругу" и демонстрирует, почему порядок результатов, возвращаемых оператором SELECT, не может быть гарантирован без условия ORDER BY.

Например, допустим, что некая таблица содержит 500 000 страниц. UserA выполняет инструкцию Transact-SQL, требующую проверки таблицы. Когда это сканирование обработало 100 000 страниц, UserB выполняет другую инструкцию Transact-SQL, которая сканирует ту же таблицу. Движок базы данных планирует один набор запросов на чтение страниц с номером выше 100 001 и передает строки из каждой страницы обратно в оба сканирования. Когда сканирование достигает 200 000-й страницы, UserC выполняет другую инструкцию Transact-SQL, которая сканирует ту же таблицу. Начиная с страницы 20000001, ядро СУБД передает строки с каждой страницы, считываемой обратно во все три сканирования. После считывания 500 000-й строки, проверка UserA завершена, а сканирование для UserB и UserC возвращается назад и начинается чтение страниц, начиная с страницы 1. Когда ядро СУБД доходит до страницы 100 000, сканирование UserB завершается. Сканирование UserC затем продолжается самостоятельно, пока не достигнет страницы 200 000. На данный момент все сканирования завершены.

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

Связанный контент

• Руководство по архитектуре Pages и экстентов
• Запись страниц в ядро СУБД