Следующий запрос (листинг 24.6) является правильным с точки зрения использования индекса. В данном случае просмотр значений столбца осуществляется слева направо.

SELECT *

FROM car WHERE Make LIKE

В листинге 24.7 индекс не используется, потому что просмотр значений столбца осуществляется справа налево (метасимвол % стоит вначале).

SELECT * FROM car WHERE Make LIKE

Дескрипторы файлов

Сервер MySQL представляет собой один процесс со множеством потоков. Для каждого сеанса подключения к серверу создается свой поток. Каждому потоку требуется один или несколько дескрипторов файлов, чтобы он мог осуществлять чтение и запись таблиц. Операционная система ограничивает количество файловых дескрипторов, доступных процессу. Это число может быть самым разным. Например, в AIX оно равно 2000 по умолчанию, а в Solaris - всего лишь 64. BLinux лимит по умолчанию составляет 1024 дескриптора. В Windows NT и 2000 видимыйпредел отсутствует.

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

Размер кэша дескрипторов можно задать другим, но не забывайте об ограничении, которое накладывается операционной системой. Правда, ее собственный лимит тоже можно изменить. Для этого суш,ествует, например, команда ulimit. Еш,е один способ -перекомпиляция ядра.

Чтобы получить доступ к таблице, поток должен иметь в своем распоряжении дескриптор ее файла данных. Все потоки совместно владеют дескриптором индексного файла. Таким образом, когда три потока одновременно извлекают данные из таблицы, используются четыре дескриптора. Если таблица дважды указана в предложении FROM, например в случае операции самообъединения, программа MySQL вынуждена открывать отдельный дескриптор для каждой ссылки на таблицу.

Системная память 447

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

Системная память

В MySQL специальные буферы и кэши используются для сам1х разнгх целей. Их размеры можно задавать в конфигурационном файле или в командной строке запуска сервера. Соответствующие опции описывались в главе 14, Утилиты командной строки . -

У каждого потока есть свой стек, буфер приема входных данных от клиента и буфер результатов запроса. Размер стека задается серверной переменной thread stack, а размерьюбоих буферов - переменной net butfer length. Последняя определяет начальные размеры буферов, так как они могут увеличиваться в случае необходимости, например при обработке столбцов типа BLOB или TEXT.

Все потоки совместно используют индексный буфер. Его размер определяется переменной keyjouffer size. В операциях объединения, проходящих без участия индексных столбцов, используется отдельный буфер (переменная join buf fer size), как и в операциях сканирования таблиц (переменная record buffer).

Если для выполнения операции объединения требуется временная таблица, она создается как резидентная (тип Heap). Максимальный размер таких таблиц определяется переменной tmp table size. После превышения этого предела таблица преобразуется в формат MylSAM. В любом случае временные таблицы удаляются по окончании операции.

Журнальные файлы

Помимо журналов транзакций, создаваемых для некоторых типов таблиц, в MySQL имеются еще семь различных журналов, все - необязательные. Если такие журналы начали вестись, то нужно следить за их размерами, поскольку они непрерывно разрастаются, причем некоторые- довольно быстро. Журнальные файлы можно удалять вручную после остановки сервера или поручить эту задачу сценарию. В дистрибутив MySQLдля RedHat Linux входит сценарий ротации журнальных файлов, который называется mysql-log-rotate. Его можно периодически запускать с помощью демона с г on.

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

Двоичный журнал

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

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

По умолчанию данный файл создается в каталоге данных, а его имясоотэетствует имени компьютера с добавлением префикса -bin и порядкового номера. Типичное имя выглядит так Vvar/red-bin. 001. Если выполнить инструкцию FLUSH LOGS, будет создан новый журнальный файл со следующим порядковым номером. Имена журнальных файлов отслеживаются в файле с расширением . index.

Утилита my sqlbinlog читает двоичный журнал и записывает извлеченные из него инструкции в поток Stdout. Их можно направить утилите mysql, чтобы воспроизвести все изменения. Это хороший способ восстановления базы данных после краха (он описывается в главе 25, Устранение последствий катастроф ). В листинге 24.8 показаны две записи двоичного журнала, о которых сообщила утилита

# at 171

#010605 11:52:14 server id 1 Query thread id=2 exec time=0

error code=0

use freetime;

SET TIMESTAMP=991767134;

UPDATE session SET LastAction = now{) WHERE ID=fNbbnOLBYYlqesga ;

# at 269

#010605 11:52:14 server id 1 Query thread id=2 exec time=l

error code=0

use freetime;

SET TIMESTAMP=991767134;

DELETE FROM project view WHERE Project=2 AND User=2;

В схеме репликации, применяемой в двоичный журнал используется для

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

Изменения, сделанные в ходе транзакции, сохраняются в кэше, пока не будет выполнена инструкция COMMIT. Максимальный размер резидентного кэша определяется переменной binlog cache size. Если размер резидентной таблицы превышает этот предел, изменения записываются во временный файл.

Двоичный журнал пришел на замену журналу обновлений, который использовался в старых версиях MySQL.

Журнал отладки

Если скомпилировать клиент или сервер MySQL с включением средств отладки, то программа начнет вести журнал отладки. По умолчанию отладочная информация записывается в файл / tmp/mysql. trace, но этуустановкуможно изменить с помощью опции-debug.