Одним из применений этой стратегии является доступ к базе данных с Web-сервера при регистрации на Web-странице. В этом случае не будет критичным решением размещение новых записей прямо в главной таблице.

Еше одной стратегией уменьшения количества обращений к таблице можно назвать использование опции delayed key write во время создания таблиц в формате MylSAM. Это можно делать тогда, когда потеря одной записи при сбое системы не будет критичной. (Это может быть случай использования СУБД MySQL для регистрации в системе.) Эта опция делает обновление индекса событием достаточно редким.

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

Проблемы планирования и блокировки

Все предьщущие разделы посвящались прежде всего методам ускорения работы запросов отдельных клиентов. СУБД MySQL позволяет изменять индивидуальные приоритеты выполнения запросов, что позволяет эффективно взаимодействовать разным клиентам таким образом, чтобы не возникали длительные блокировки. Изменение приоритетов может привести к повышению быстродействия отдельных типов запросов. Сначала познакомимся со стратегией планирования, принятой в СУБД MySQL по умолчанию, а затем посмотрим, каким образом можно на нее повлиять. Сначала определимся с терминами. Назовем читателем клиента, осуществляющего выборку (оператор select). Клиента, осуществляющего операции модификации записей таблицы (операторы delete, insert, replace ИЛИ update), Назовем писателем.

Вкратце стратегию планирования СУБД MySQL можно определить так.

Запросы записи должны выполняться в порядке их поступления.

Запросы, выполняющие операцию записи, имеют более высокий приоритет, чем запросы, выполняющие операцию чтения.

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

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

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

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

СУБД MySQL позволяет оказьшать влияние на стратегию планирования с помощью специфических модификаторов запросов. Одним из таких модификаторов является ключевое слово low priority в операторах delete, insert, load data, replace и update. Вторым модификатором является ключевое слово high priority для операторов select. Третьим модификатором является ключевое слово delayed для операторов insert и replace.

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

Если запрос на запись объявлен как lowpriority, операция записи будет иметь приоритет ниже, чем операция чтения. В этом случае, если второй читатель обращается во время ожидания операции записи, его операция будет выполнена до операции записи. Только в случае, когда читателей, ожидающих своей очереди на выполнение больше нет, писатель сможет продолжить свою работу. Одним довольно существенным осложнением, которого можно ожидать от такого изменения стратегии планирования, является то, что теоретически вероятно, что писатель с модификатором L0W PRI0RITY будет заблокирован навсегда. Если во время, когда запрос писателя уже ожидает выполнения запросов на чтение, будут поступать новые, очередь писателя не наступит никогда.

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

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

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

Влияние INSERT DELAYED НЭ рзботу КЛИвНТЭ

Модификатор insert delayed может очень пригодиться в случае, когда клиенты запускают длительные запросы select, а администратор не хочет сталкиваться с ситуацией длительной блокировки операций добавления Клиент, выдающий запрос insert delayed, сможет продолжать работу, потому что сервер просто ставит запросы на добавление записей в очередь.

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