MySQL. Библиотека профессионала - Аткинсон Л

442 Глава 24. Физическое хранение данных

По умолчанию в каждой таблице может быть не более тридцати двух индексов, но

си. Выбор между фиксированным и динамическим форматом диктуется определе ниями столбцов. Для сжатых таблиц предназначена утилита (см. главу 14, "Утилиты командной строки").

Таблица будет иметь записи фиксированной длины, если в ней нетстолбцов типа

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

Все записи таблицы будут динамическими, если в ней есть столбцы типа VARCHAR, BLOB или TEXT. Возможно также приведение столбцов типа CHAR к типу VARCHAR, ес ли их длина больше четырех символов. Длина каждой записи отслеживается по спе циальному заголовку. В нем указана длина текущего сегмента записи. Поскольку при

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

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

Если таблица MylSAM находится на переполненном диске и в нее добавляется за пись, программа MySQLперейдет в бесконечный цикл, ожидая освобождения места на диске.

Столбцы

В табл. 24.1 указаны размерности стандартных типов данных MySQL. Значения некоторых типов всегда занимают фиксированный объем памяти. Например, раз мерность столбцов типа INTEGER всегда составляет 4 байта. Столбцы типа CHAR могут иметь размерность от 0 до 255, но в момент создания таблицы под них отводится фиксированный объем памяти. Существуют также столбцы переменной размерности. Например, столбцы типа VARCHAR и BLOB интерпретируются в соответствии с их держимым.

Столбцы 443

444 Глава 24. Физическое хранение данных

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

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

Блокировки таблиц

ВMySQL разрешается явно блокировать таблицы с помощью инструкции LOCK TABLES. Тем неменее не рекомендуется делать это для таблиц тех типов, которые

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

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

Можно заблокировать таблицу таким образом, чтобы разрешить другим потокам ращаться к ней для чтения. Этоназывается блокировкой чтения. Блокировка записи га рантирует текущему потоку монопольный доступ к таблице. Запросы на чтение откла дываются до тех пор, пока не будут сняты все блокировки записи. Эту установку можно изменить с помощью флагов инструкций либо путем задания специальных серверных переменных. Для SQL инструкций создаются две очереди. Чтобы программа MySQL на чала извлекать инструкции из очереди на чтение, очередь на запись должна быть пуста. При наличии флага инструкции DELETE, INSERT и UPDATE помещаются

вочередь на чтение, т.е. они получают такой же приоритет, что и инструкции SELECT. Флаг HIGH_PRIORITY переводитинструкцию SELECT в очередь на запись.

Индексы

В MySQL индексы хранятся в виде двоичных деревьев. Деревья перестраиваются по мере вставки записей. Это означает, что каждый индекс вызывает небольшое снижение производительности. Как правило, индексы повышают скорость операций выборки за счет снижения скорости операций записи. Тем не менее наличие индекса еще не гаран тирует никакого ускорения. Нужно соотносить их с теми запросами, которые планиру ется выполнять. Чтобы понять, насколько эффективным окажется тот или иной ин декс, пользуйтесь инструкциейEXPLAIN (рассматриваетсявглаве26, "Оптимизация").

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

Индексы 445

Индексы способны повысить производительность инструкций, связанных с поиском Они ускоряют процесс сравнения столбцов при выполнении операций динения. Кроме они помогают находить минимальное и максимальное значения столбца и ускоряют выполнение инструкций SELECT с предложением ORDER BY.

Чтобы индекс был задействован, он должен быть указан во всех частях

ния WHERE. Если используется лишь часть индекса, то должен соблюдаться порядок обращения к индексируемым столбцам: слева направо. Для примера рассмотрим таб лицу, определение которой приведено в листинге 24.2.

У таблицы car имеется составной первичный ключ. В запросе, который показан в листинге 24.3, индекс будет использован, так как столбец Make является самым левым компонентом индекса.

SELECT *

FROM car

WHERE

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

нент индекса нельзя применить к каждой записи. Если бы в предложении WHERE сто ял оператор AND, а не OR, всебыло бы наоборот.

SELECT *

FROM car

WHERE

OR

446 Глава 24. Физическое хранение данных

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

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

SELECT *

FROM car

WHERE Make LIKE

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

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

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

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

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

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

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

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

ределяет начальные размеры буферов, так как они могут увеличиваться в случае

дексных столбцов, используется отдельный буфер (переменная как и в операциях сканирования таблиц (переменная

Если для выполнения операции объединения требуется временная таблица, она создается как резидентная (тип Heap). Максимальный размер таких таблиц определя ется переменной tmp_table_size. После превышения этого предела таблица

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

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

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

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

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

448 Глава 24. Физическое хранение данных

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

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

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

at 171

#010605 server id 1 Query thread_id=2 exec_time=0 error_code=0

use freetime;

SET

UPDATE session SET WHERE

at 269

#010605 11:52:14 server id 1 Query thread_id=2

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

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

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

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

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

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

В MySQL используется библиотека функций отладки, которую написал Фред Фиш (Fred Fish). Подробнее об отладке MySQL рассказывается в главе "Расширение возможностей MySQL".

Журнал ошибок

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

010605 12:36:32 started

Started

ready for connections

010605 12:37:01 /usr/local/libexec/mysqld: Normal shutdown

010605 12:37:01 Aborted connection 1 to user: host: (Got timeout reading communication packets) 010605 12:37:01 Aborted connection 2 to db: user: host: (Got timeout reading communication packets) InnoDB: Starting

InnoDB: Shutdown completed

010605 12:37:01 /usr/local/libexec/mysqld: Shutdown Complete

010605 12:37:01 mysqld ended

Журнал ошибок находится в каталоге данных. Его имя соответствует имени ком пьютера сдобавлениемрасширения err.

Чтобы включить журнал MylSAM, необходимо запустить сервер с опцией am. Разработчики MySQL используют этот журнал для отладки обработчика таблиц MylSAM. Журнальный файл создается в каталоге данных под именем Существует утилита предназначенная для сбора статистической инфор мации из этого файла (см. главу 14, "Утилиты командной строки"). В листинге 24.10 показаны результаты работы этой утилиты.

450 Глава 24. Физическое хранение данных

Информация, хранящаяся в данном журнальном файле, представляет интерес только для разработчиков MySQL.

Журналзапросов

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

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

Журнал медленных запросов

В журнале медленных запросов регистрируются инструкции, которые выполня лись слишком долго. Соответствующий предел задается в серверной переменной long_query_time. Если при запуске сервера была указана опция format, то в данном журнале будут также фиксироваться запросы, в которых не ис пользуются индексы. Журнальный файл создается в каталоге данных, а его имясоот ветствует имени компьютера с добавлением расширения log.

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

SELECT FROM comment user WHERE N AND AND N

delete from session where

Журналобновлений

Журнал обновлений применялся в старых версиях MySQL и в настоящее время заменен двоичным журналом.