WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!

Pages:     | 1 |   ...   | 3 | 4 || 6 | 7 |

«Содержит примеры проектирования и систем корпоративного уровня и подробные объяснения к ним главы по вопросам хранения распределенных баз и другим сложным темам Леоном ведущим специалистом с ...»

-- [ Страница 5 ] --

Изменение данных Если требуется выполнить инструкцию, которая не возвращает набор записей (например, CREATE STATEMENT), воспользуйтесь методом do объекта базы дан ных. Этот метод возвращает число измененных записей. Для запросов, которые вы полнились успешно, но не меняли никаких записей, возвращается специальное зна чение Представленный ниже сценарий со здает таблицу и добавляет в нее записи. Далее происходит удаление части записей, обновление записей и, наконец, удаление всей таблицы. Обратите внимание на способ вставки записей. В массиве name содержатся Глава 20. Perl девять имен, вставляемых в базу данных. В цикле for вызывается метод execute в котором параметру инструкции INSERT (обозначается символом по очереди при сваиваются значения, хранящиеся в массиве. Учитывая, что в MySQL поддерживается многострочная инструкция INSERT, не самый эффективный метод вставки имен, но он удобен, когда требуется выполнять произвольные пользовательские запросы.

Подключение модуля use DBI;

my my Подключение к базе данных.

my $dbh Создание таблицы.

$query "CREATE TABLE "ID (11) NOT NULL "Name "PRIMARY or die execute $query: $dbh >errstr $query "INSERT INTO testapi (Name) VALUES my my $sth or die prepare $query: $dbh >errstr my $n or die "Can't execute $query: $dbh >errstr row Удаление записей.

FROM testapi WHERE ID 4";

$rows or die execute $query: $dbh >errstr rows tt Обновление записей.

Изменение данных SET Name $rows or die execute $query: $dbh >errstr rows I Удаление таблицы.

TABLE testapi";

or die execute $query: $dbh >errstr PYTHON В этой главе.

• Подготовка программы • Извлечение данных • Изменение данных van назвал свой объектно ориентированный язык сценариев Python в честь известного британского комедийного телесериа ла "Monty Python's Flying Circus". Сценарии Python выполняются в UNIX, Win dows и многих других операционных системах. Язык Python ценится многими за про стоту изучения.

В этой главе рассматривается библиотека языка Python, предназна ченная для взаимодействия с серверами MySQL. что читатели умеют писать программы на этом языке. Тем, кому он в диковинку, советуем посетить узел www.python.org. Там есть много ресурсов, посвященных изучению языка.

Подготовка программы Авторы проекта Python разработали спецификацию DBI API 2.0 для д райверов баз данных. Благодаря этому взаимодействие с базами данных осуществляется унифици рованным образом. Драйвер MySQL реализован Энди (Andy Dustman) и доступен по адресу http://dustman.net/andy/python/MySQLdb либо Там можно загрузить исходные коды и модули для Linux. Ес ли сценарии Python предполагается запускать в Windows, то (Gerhard предлагает скомпилированную версию библиотеки MySQLdb на своем узле по адресу Подробное описание процедуры инсталляции выходит за рамки данной книги.

В архивах MySQLdb содержатся сведения по компиляции и инсталляции модуля.

Сценарий автоматически управляет всем процессом.

Подключиться к серверу MySQL из сценария Python несложно. Достаточно им портировать модуль MySQLdb и вызвать метод Connect Параметры метода пере числены в табл. 21.1. Он возвращает объект Connection, который можно использо вать для получения объекта Cursor.

Глава Python Параметр Описание Стандартная база данных Имя или IP адрес узла Пароль Port TCP/IP Путевое имя user Имяпользователя В листинге 21.1 показан минимальный сценарий подключения к серверу MySQL, расположенному на узле Имя базы test. В сценарии создается указатель набора записей. Вообще то в MySQL не разрешен непосредственный доступ к указателям, но в библиотеке эти функции имитируются.

import MySQLdb Подключение к серверу баз данных.

= Создание указателя набора cursor Отключение.

Извлечение данных После подключения к серверу баз данных можно посылать ему запросы с помощью методов execute и Оба они вкачестве первого аргумента при нимают текст запроса.

Инструкция SELECT и ряд других инструкций, в частности SHOW PROCESSLIST, воз вращают результаты в виде набора записей. Метод f возвращает дующую запись из набора, а метод f возвращает весь набор в виде массива.

В листинге 21.2 показан сценарий, который извлекает данные из таблицы user и отображает их в виде таблицы. Обратите внимание на то, что сценарий пытается подключиться к серверу от имени пользователя root с явно неправильным паролем.

Если будете экспериментировать с этим сценарием, подставьте корректные значения имени пользователя и пароля.

Извлечение данных import Подключение к серверу баз = Создание указателя набора cursor Выполнение User, Host FROM user ORDER BY 1,2") Отображение заголовка for field in width field[2] print % (width, print for field in line for in range line print line, fieldLen print Отображение результатов запроса.

for in resultSet:

f= for in cursorRecord:

width print % (width, f print Закрытие соединения.

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

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

Обратите внимание на спецификацию * в команде Она позволяет задавать размерность на этапе выполнения сценария.

418 Глава Python Изменение данных Запросы на вставку или обновление данных не возвращают наборы записей. Они тоже выполняются с помощью метода execute но извлекать записи нет необхо димости. Если требуется узнать число добавленных или измененных записей, вос пользуйтесь свойством rowcount объекта cursor.

Сценарий, показанный в листинге 21.3, создает таблицу и добавляет в нее записи.

Далее происходит удаление части записей, обновление записей и, наконец, удаление всей таблицы. Обратите внимание на способ вставки записей. В массиве names со держатся девять имен, добавляемых в таблицу путем вызова метода Вместо значения имени в тексте запроса стоит специфика ция которая заменяется реальным значением при вызове метода executemany Вторым аргументом этого метода является массив списков. Каждый список ствует одной добавляемой записи, а элементы па раметрам запроса. В лис тинге 21.3 у инструкции INSERT один параметр, поэтому кажется, будто в определе нии массива names стоит слишком много скобок и запятых. На самом деле хвостовые запятые нужны для правильного определения типа массива.

import Подключение к серверу баз данных.

= Создание указателя набора cursor Создание query \ "CREATE TABLE \ "ID NOT NULL \ "Name \ "PRIMARY \ Вставка записей.

query "INSERT INTO testapi (Name) VALUES names names) print rows inserted" Удаление FROM testapi WHERE ID 4") print str rowcount) rows deleted" Обновление Изменение данных testapi SET Name print rows updated" Удаление таблицы.

TABLE testapi") БИБЛИОТЕКА MYSQL++ В этой главе.

• Подготовка программы • Извлечение данных • Изменение данных руппа разработчиков MySQL выпустила официальную библиотеку классов языка C++, предназначенных для взаимодействия с MySQL. Изначально написанная Кевином (не родственник), она в настоящее время со провождается уже упоминавшимся Библиотека работает с большинством компиляторов включая GNU C++ и Visual C++компа нии Microsoft.

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

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

с++ о minimal \ \ 422 Глава 22. Библиотека MySQL++ Естественно, в более сложных случаях необходимо создавать Подключиться к серверу MySQL средствами библиотеки несложно: дос таточно создать объект класса Connection. У этого класса четыре конструктора:

Connection Connection te) Connection (const char *db, const char *host const char *user const char *passwd bool te Connection (const char *db, const char *host, const char const char *passwd, port, compress 0, unsigned connect_timeout 60, bool te true, unsigned int В основном аргументы конструктора соответствуют аргументам функции библиотеки языка С. Аргумент te определяет, будут ли ге нерироваться исключения.

В листинге показан текст минимального клиента. Эта программа ся к базе данных test на узле localhost. Код очистки не нужен, так как деструктор класса Connectionсамостоятельно закрывает соединение.

ttinclude ttinclude int char Подключение к серверу.

Connection con "localhost", return 0;

Извлечение данных Подключившись к серверу баз данных, программа создать объект класса Query, с помощью которого будут посылаться запросы. Этот класс является потомком класса но ему разрешается посылать лишь входные данные, а оператор не поддерживается. Чтобы направить запрос серверу, необходимо записать его в поток с помощью оператора и вызвать метод Query: : store либо Query: execute Первый из них возвращает таблицу результатов запроса.

В листинге 22.2 показана простая программа, которая извлекает данные из табли цы user. Обратите внимание на то, что программа пытается подключиться к серверу от имени пользователя root с явно неправильным паролем. Если будете эксперимен тировать с этой программой, подставьте корректные значения имени пользователя и пароля.

Извлечение данных Обратите также внимание на использование итератора класса Result в цикле На каждом шаге цикла создается объект класса Row, который ведет себя как мас сив строк. возвращает число полей записи.

#include #include main(int char try Подключение к серверу.

Connection "root", Создание объекта запроса.

Query query Отправка запроса.

query "SELECT User, Host FROM user ORDER BY 1,2";

Получение результатов запроса.

Result res Отображение записей.

Row row;

i;

for (i i i++) row *i;

for (unsigned int j++) cout return 0;

catch "Error:

endl;

return 1;

424 Глава 22. Библиотека Изменение данных Метод : execute предназначен для выполнения которые не возвращают результаты в виде наборов записей. С помощью метода Connection:

ected_rows можно узнать число добавленных, удаленных или обновленных записей (листинг 22.3).

#include char try Подключение к серверу.

Connection Создание объекта запроса.

Query query Создание таблицы.

query "CREATE TABLE IF NOT EXISTS "ID. NOT NULL "Name "PRIMARY Вставка записей.

const char "Leon", "Vicky", "Carl", "Jeff", "Bob", "Tina", "Joey" Подготовка запроса.

query "INSERT INTO %0 (Name) VALUES i=0;

i++) Выполнение запроса.

Изменение данных row inserted" endl;

Удаление query "DELETE FROM WHERE ID rows deleted" endl;

Обновление query "UPDATE testapi SET Name cout rows updated" endl;

Удаление таблицы.

query "DROP TABLE testapi";

return 0;

catch "Query Error: endl;

return 1;

Программа, представленная в листинге 22.3, создает таблицу и добавляет в нее за писи. Далее происходит удаление части записей, обновление записей и, наконец, уда ление всей таблицы. Обратите внимание на способ вставки записей. Инструкция INSERT, переданная объекту query, содержит коды начинающиеся с символа Стоящий затем номер определяет порядок аргументов метода execute В данном примере методу требуется узнать имя таблицы и значение столбца. Символ говорит о том, что значение берется в кавычки.

Для параметризованных запросов должен вызываться метод Query:

позволяющий правильно пометить параметры. При выполнении запроса нужно ука зывать значение каждого параметра. Можно также задать стандартные значения па раметров, чтобы метод execute их не требовал. Для этого предназначен вый массив ТЕМЫ части рассматриваются сложные темы, которые могут быть неинтересны рядовым пользователям MySQL. Представленный здесь материал предназначен, скорее, администраторам баз дан ных, стремящимся повысить производительность своей СУБД или рас ширить ее функциональные возможности.

В главе 23, "Администрирование баз данных", читатели узнают о том, какая ответственность лежит на администраторе баз данных. В главе 24, "Физическое хранение данных", рассказывается о принципах использова ния физических ресурсов в MySQL. В главе 25, "Устранение последствий катастроф", описываются стратегии предотвращения катастроф и устра нения их последствий. Сюда входит восстановление поврежденных таблиц и создание резервных копий. Глава 26, "Оптимизация", посвящена сам оптимизации баз данных и запросов. В главе 27, "Безопасность", рас сматриваются вопросы обеспечения безопасности баз данных.

В главе 28, "Перенос данных в разные СУБД", рассказывается о том, зачем может понадобиться перейти из другой СУБД в MySQL или из MySQL — в другую СУБД и какие нюансы необходимо при этом учесть.

В главе "Распределенные базы данных", рассматриваются концеп ции распределенных баз данных. В частности, описываются принципы синхронизации и репликации таких баз данных.

В главе 30, "Работа с объектами", описывается применение ориентированных методик при работе с базами данных. Приводится пример работы с объектами баз данных на Глава "Расширение возможностей MySQL", посвящена расшире нию функциональных возможностей MySQL. Сюда входит добавление новых наборов символов, функций и процедур. Рассматривается также библиотека функций отладки MySQL.

БАЗ ДАННЫХ этой Ответственность Обеспечение доступности данных Поддержание целостности данных Подготовка к катастрофе Поддержка пользователей Разработка и внедрение стандартов главе выполняемые администратором баз дан ных. Отдельный человек или целая команда принимает на себя ответствен ность за непрерывное функционирование сервера MySQL и обязуется непре рывно выполнять анализ производительности, устранять проблемы и настраивать конфигурацию.

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

Перечислим пять основных обязанностей администратора:

• обеспечение доступности данных;

• поддержание целостности данных;

• подготовка к катастрофе;

• поддержка пользователей;

• разработка и внедрение стандартов.

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

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

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

Не полагайтесь лишь на скорость передачи данных, которой обладает жесткий диск. Производительность SCSI дисков будет выше, чем IDE дисков, поскольку в тех нологии SCSI поддерживаются одновременные операции чтения. Еще больше повы шает производительность технология RAID (Redundant of Independent Disks — матрица независимых дисковых накопителей с избыточностью), в которой группа дисков представляется единым устройством. Программа MySQL поддерживает эту технологию, позволяя распределять данные между несколькими файлами, которые могут находиться на разных дисках.

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

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

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

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

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

diff 62абЗ INSERT INTO VALUES 170al INSERT INTO user VALUES Просмотр журнальных файлов MySQL позволяет выявить необычные операции или обнаружить признаки неэффективной организации таблиц. Подробнее о журнальных файлах, создаваемых программой MySQL, рассказывается в главе 24, "Физическое хра нение данных". Эти файлы очень быстро разрастаются, поэтому необходимо регулярно осуществлять их ротацию. С помощью инструкции FLUSH LOGS можно заставить вер начать новые журнальные файлы, но предварительно следует переименовать суще ствующие файлы и поместить самый старый файл в архив. В Linux дистрибутив MySQL входит сценарий автоматизирующий этот процесс.

Регулярно проверяйте таблицы на предмет наличия в них ошибок. Подобную верку также можно делать в автоматическом режиме. В UNIX для этого используется программа а в Windows —программа планировщик. Поиск ошибок в таблицах можно вести с помощью утилиты или инструкции CHECK TABLES.

Не забудьте сохранить полученные результаты в файле для последующего анализа.

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

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

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

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

Не забудьте протестировать средства восстановления данных. Инсталлируйте MySQL в другой системе и восстановите резервную копию на "пустом месте". Регу лярно проверяйте архивы, чтобы защитить себя от неприятных сюрпризов.

О создании резервных копий и восстановлении таблиц будет рассказываться в главе 25, "Устранение последствий катастроф".

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

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

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

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

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

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

Если база данных каждый день увеличивается на 100 Мбайт, очень скоро понадобится покупать новый жесткий диск или же сбрасывать старые данные в архив. Довольно часто происходят изменения самой программы MySQL. Организуйте регулярное об новление версий программы. Разработчики MySQL всегда сообщают о том, насколько "стабилен" тот или иной выпуск, чтобы пользователи могли решить, стоит ли на него переходить. Следите за новыми возможностями программы, которые позволят повы сить эффективность работы с системой.

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

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

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

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

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

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

ФИЗИЧЕСКОЕ ХРАНЕНИЕ ДАННЫХ этой Способ хранения таблиц и баз данных Выделенные разделы Типы таблиц Столбцы Блокировки таблиц Индексы Дескрипторы файлов Системная память Журнальные файлы главе рассказывается о том, как в MySQL организуется физическое хране ние данных. Описывается способ представления таблиц на жестком диске и формат журнальных файлов. Понимание этих вопросов важно для создания эффективных баз данных.

Способ хранения таблиц и баз данных В MySQL таблице соответствует несколько файлов. Их имена совпадают с именем таблицы, а расширение определяет назначение файла. К примеру, файл с расшире нием содержит описание структуры таблицы. Что касается баз данных, то они являются подкаталогами основного каталога (по умолчанию это Имя подкаталога соответствует имени базы данных. Это означает, что имена баз данных и таблиц отвечают тем же требованиям, которые предъявляются к именам файлов в данной системе. Скажем, файловая система ext2 в Linux чувстви тельна к регистру символов, a FAT32 в Windows — нет.

Операционные системы налагают свои ограничения на максимальный размер файла. Обычно он составляет от 2 до 4 Гбайт. Для таблиц типа описываемо го ниже, все данные сохраняются в одном файле, следовательно, максимальный раз мер файла одновременно является максимальным размером таблицы.

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

436 Глава 24. Физическое хранение данных Выделенные разделы В некоторых СУБД поддерживаются выделенные файловые системы. Такая фай ловая система инсталлируется в собственный дисковый и лишь СУБД знает, как ее использовать. Сервер берет на себя выполнение всех функций файловой сис темы, тогда как обычно они предоставляются самой операционной системой. Теоре тически это способствует повышению производительности.

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

Управление файлами в рамках операционной системы имеет свои преимущества.

Во первых, разработчики системы проделывают огромную работу по отладке соот ветствующих функций, а во вторых,появляется возможность пользоваться стандарт ными утилитами обработки файлов. Создать резервную копию базы данных MySQL можно с помощью обычной утилиты tar, а не специализированной программы. Вы деленные файловые системы требуют целого набора управляющих утилит, в частно сти для проверки и восстановления файлов. Всего этого нет в MySQL Типы таблиц В MySQL версии 3.23.37 поддерживаютсясемь типов таблиц. Три из них — Gemini и — ориентированы на транзакции, а четыре — Heap, ISAM, Merge и — нет. Транзакции являются относительно новым понятием в MySQL, но ветствующие функции для таблиц Berkeley DB и InnoDB существуют уже достаточно давно, что позволило включить их в стандартные бинарные дистрибутивы. Подробнее об этом рассказывалось в главе 9, "Транзакции и параллельные вычисления".

Стандартным типом таблиц в MySQL является тип MylSAM. Он возник на основе более старого типа ISAM, который все еще существует, хотя использовать его не комендуется. Переопределить установку по умолчанию позволяет опция TYPE инст рукций CREATE TABLE и ALTER TABLE (см. главу 13, "Инструкции SQL").

DB Проект Berkeley DB начался в Калифорнийском университете в Беркли.

следствии его авторы сформировали компанию Software (www.sleepycat.com) и занялись распространением коммерческой версии СУБД. Многие утилиты до сих пор работают со старыми версиями (1.85 и 1.86), в то время как компания Sleepycat Software предлагает уже семейство версий 3.x и 4.x Эта СУБД свободно ся с исходными кодами, и ею можно пользоваться бесплатно, за исключением случаев, когда на ее основе планируется создавать приложения, не распространяемые на услови ях открытой лицензии.

Типы таблиц BDB — это простая файловая СУБД, поддерживающая транзакции, но не распола гающая каким либо языком запросов. В MySQL эта СУБД нужна для того, чтобы мож но было работать с таблицами в режиме транзакций.

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

Разработчики MySQL тесно сотрудничают с программистами компании чтобы гарантировать максимальную эффективность использования библиотеки BDB.

Вообще то, поддержка BDB в MySQL появилась не так давно (в версии 3.23.24), но, учитывая высокую стабильность обоих продуктов, их интеграция не привела к воз никновению каких либо трудностей для пользователей. Разработчики MySQL плани руют и дальше улучшать поддержку BDB.

С функциональной точки зрения таблицы BDB ведут себя аналогично таблицам Нет никаких ограничений на число столбцов или индексов, как в случае ре зидентных таблиц. Единственное условие: для таблиц BDB обязательно наличие пер вичного ключа. Если он не задан, MySQL самостоятельно создаст внутренний пер вичный ключ, охватывающий первые пять байтов каждой записи. К таблицам BDB можно применять инструкцию LOCK TABLES, но при частой работе с такими табли цами лучше пользоваться преимуществами транзакций.

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

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

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

СУБД BDB не ведет подсчет записей в таблицах, но MySQL хранит собственный счетчик. Он используется модулем оптимизации объединений при выборе индексов.

Значение счетчика может быть неточным, если произошел сбой базы данных, но счетчик можно сбросить с помощью инструкции ANALYZE TABLE или OPTIMIZE TABLE. Ведение счетчика записей немного замедляет работу с таблицами BDB.

Табличные данные хранятся в виде двоичного дерева. Это более медленный ме тод, чем тот, который применяется для таблиц MylSAM. СУБД BDB оставляет в дере 438 Глава 24. Физическое хранение данных пустые позиции, чтобы операции вставки выполнялись быстрее. В результате раз мер файла становится больше, чем нужно.

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

Gemini Функции работы с таблицами Gemini реализовали программисты компании (www.nusphere.com). Эта компания обеспечивает поддержку и обучение поль зователей MySQL. Бета тестирование таблиц Gemini началось в апреле 2001 г. и на момент написания книги еще продолжалось.

В этих таблицах отсутствуют столбцы типа BLOB и TEXT. Количество лей, которые могут одновременно работать с таблицами, по умолчанию равно 100.

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

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

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

Резидентные таблицы не располагают многими возможностями обычных таблиц.

Они не могут иметь столбцы типа BLOB или TEXT. Нельзя использовать флаг AUTO_INCREMENT. Можно создавать индексы, но нельзя индексировать столбцы, до пускающие значения NULL. Индексы используются только в операциях и Записи резидентных таблиц имеют фиксированную длину. Для столбцов типа VARCHAR сразу выделяется максимальное число байтов. Поскольку ограни ченный ресурс, можно задать предельное количество записей в резидентной таблице.

Для этого предназначена опция инструкции CREATE TABLE. Серверная переменная задает максимальный объем памяти, занимаемой всеми резидентными таблицами.

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

Типы таблиц СУБД InnoDB была разработана из компании — финского производителя программного обеспечения, спе циализирующегося на технологии реляционных баз данных. InnoDB представляет собой исследований, проводимых Хейкки в университете Хельсинки. Под держка InnoDB появилась в MySQL версии 3.23.34а. Сама СУБД доступна на условиях открытой лицензии.

На Web узле InnoDB можно найти массу информации о деталях работы ядра этой СУБД. Ядро не существует само по себе, а является дополнением к MySQL. С Web узла MySQL можно загрузить скомпилированную версию программы, в которую встроена поддержка InnoDB. Если впоследствии потребуется отключить эту поддержку, доста точно будет запустить демон с опцией На этапе компиляции MySQL поддержка InnoDB включается с помощью опции Исходные коды InnoDB входят в исходный дистрибутив MySQL.

В отличие от таблиц где для каждой таблицы создается один файл дан ных, данные InnoDB хранятся в больших совместно используемых файлах. Можно создать произвольное число файлов данных, но их нельзя будет удалить. Размер фай лов определяется в конфигурационном файле. Если нужно уменьшить объем го пространства, занимаемого таблицами InnoDB, создайте резервные копии таблиц, после чего удалите все файлы InnoDB и позвольте программе MySQL восстановить их в соответствии с новыми установками файла. Журнальные фай лы InnoDB можно безопасно удалить после остановки сервера. При повторном запус ке сервера программа MySQL создаст журнальные файлы заново.

В листинге 24.1 приведен пример опций, которые необходимо добавить в конфи гурационный файл в группу чтобы активизировать таблицы InnoDB. Раз мер файлов здесь задан относительно небольшим, что вполне подходит для целей эксперимента. На практике используются файлы гораздо большего размера. Список опций и переменных демона mysqld был приведен в главе 14, "Утилиты командной строки".

innodb_data_home_dir set variable /disk2/innodb/log set variable set variable innodb_log_file_size=16M set variable innodb_log_arch_dir /disk2/innodb/log innodb_log_archive= set variable set variable set variable innodb_file_io_threads= set variable lock wait 440 Глава 24. Физическое хранение данных После добавления опций в конфигурационный файл необходимо перезапустить сервер MySQL. Все не обходимые файлы будут созданы автоматически. На это может уйти некоторое время, в зависимости от размера файлов и скорости жесткого диска.

Таблицы InnoDB блокируются на уровне записей. Это происходит без участия пользователей по мере выполнения инструкций в рамках транзакций. Инструкция LOCK TABLE может конфликтовать с блокировками InnoDB. В отличие от таблиц блокировки таблиц InnoDB способны приводить к возникновению тупиков, т.е.

взаимоблокировок. В подобной ситуации одна или несколько отменяется.

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

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

На момент написания книги существовало несколько ограничений таблиц InnoDB.

Самое существенное из них заключалось в способе отслеживания таблиц. В InnoDB каталог таблиц, который не инструкцией DROP TABLE, этому каждую таблицу приходится удалять отдельно. Не разрешается индексировать префикс столбца, а также индексировать столбцы типа BLOB и TEXT. Максимальное количество столбцов в таблице— 1000. Флаг DELAYED в инструкции INSERT не под держивается.

ISAM До версии 3.23 стандартным типом таблиц в MySQL был тип ISAM. Он не обладает такими возможностями, как более новый тип поэтому в современных верси ях MySQL использовать его не рекомендуется.

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

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

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

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

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

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

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

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

MySQL хранит счетчик подключений к таблице MylSAM. Когда таблица закрыва ется, счетчик сбрасывается в нуль. Если сервер неожиданно завершает работу, чик остается положительным числом. В таком случае в процессе перезапуска сервер обнаружит проблему. Это не означает, что таблица повреждена, но подобная воз можность существует. Следует немедленно выполнить инструкцию CHECK TABLE или вызвать утилиту myisamchk. Можно также запустить демон с опцией чтобы заставить его восстанавливать все таблицы MylSAM с не нулевым значением счетчика.

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

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

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

Индексные файлы имеют расширение Файлы с расширением MYD содержат данные, а с расширением схему таблицы. Если индексный файл по какой то причине теряется, программа перестраивает индексы, используя информацию из 442 Глава 24. Физическое хранение данных По умолчанию в каждой таблице может быть не более тридцати двух индексов, но это значение можно повысить шестидесяти четырех. Индексы создаются в виде двоичных деревьев. Разрешается индексировать столбцы типа BLOB и TEXT, а также столбцы, допускающие значения NULL.

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

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

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

Динамические записи часто требуют При их удалении возникают пустые участки, которые не всегда в точности заполняются вставляемыми записями.

лее того, операций обновления длина записи может увеличиваться или уменьшаться.

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

ранить фрагментацию можно с помощью инструкции TABLES.

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

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

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

Например, столбцы типа VARCHAR и BLOB интерпретируются в соответствии с их держимым.

Столбцы Тип Размерность BIGINT 8 байтов TEXT Длина содержимого 2 байта CHAR Указанное число байтов DATE 3 байта DATETIME 8 байтов DECIMAL (длина, точность) Длина 1 байт, если точность равна 0;

в про тивном случае — длина 2 байта DOUBLE 8 байтов DOUBLE PRECISION 8 байтов ENUM 1 байт, если в перечислении менее ментов;

в противном случае — 2 байта FLOAT 4 байта FLOAT 4 байта, если длина 24;

в противном слу чае — 8 байтов INT 4 байта INTEGER 4байта LONGTEXT 2 байта MEDIUMTEXT 2 байта 3 байта NUMERIC (длина, точность) Длина 1 байт, если точность равна 0;

в тивном случае — длина 2 байта REAL 8 байтов SET 1, 2, 3;

4 или 8 байтов, в зависимости от коли чества элементов множества 2 байта TIME 3 байта TIMESTAMP 4байта TINYTEXT 2 байта TINYINT 1 байт VARCHAR Длина содержимого 1 байт YEAR 1 байт 444 Глава 24. Физическое хранение данных Как указывалось выше, таблицы содержат записи фиксированной либо переменной длины. Переход во второй режим осуществляется при наличии столбцов переменной размерности.

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

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

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

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

При наличии флага инструкции DELETE, INSERT и UPDATE помещаются в очередь на чтение, т.е. они получают такой же приоритет, что и инструкции SELECT.

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

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

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

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

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

CREATE TABLE car Make NOT NULL, Model NOT NULL, Introduced YEAR, PRIMARY Model) У таблицы car имеется составной первичный ключ. В запросе, который показан в листинге 24.3, индекс будет использован, так как столбец Make является самым левым компонентом индекса.

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

SELECT * FROM car WHERE В листинге 24.5 индекс также не из за того что самый левый нент индекса нельзя применить к каждой записи. Если бы в предложении WHERE сто ял оператор AND, а не OR, всебыло бы наоборот.

SELECT * FROM car WHERE OR 446 Глава 24. Физическое хранение данных Следующий запрос (листинг 24.6) является правильным с точки зрения использо вания индекса. В данном случае просмотр значений столбца осуществляется слева на право.

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

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

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

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

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

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

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

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

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

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

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

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

Записи файла хранятся в эффективном двоичном формате. Изменения фиксируются 448 Глава 24. Физическое хранение данных же после выполнения инструкции, но до того, как будут сняты блокировки. За писывается также информация о времени, которое ушло на выполнение инструкции.

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

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

читает двоичный журнал и записывает извлеченные из не го инструкции в поток Их можно направить утилите чтобы воспроиз вести все изменения. Это хороший способ восстановления базы данных после краха (он описывается в главе 25, "Устранение последствий катастроф"). В листинге 24. показаны две записи двоичного журнала, о которых сообщила утилита at # server id 1 Query thread_id=2 exec_time= error_code= use freetime;

SET UPDATE session SET WHERE at #010605 11:52:14 server id 1 Query thread_id= use freetime;

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

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

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

Журнал отладки Если скомпилировать клиент или сервер MySQL с включением средств отладки, то программа начнет вести журнал отладки. По умолчанию отладочная информация за писывается в файл trace, но эту установку можно изменить с помощью опции Журнальные файлы В 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. показаны результаты работы этой утилиты.

Commands Used count Errors Recover errors open 2 write 450 Глава 24. Физическое хранение данных update 2 О О delete О close 25 О О extra 220 О О Total 282 О О Информация, хранящаяся в данном журнальном файле, представляет интерес только для разработчиков MySQL.

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

Version:

started with:

port: 3306 Unix socket:

Time Id Argument 010605 11:51:45 1 Connect httpd@localhost on 1 Statistics 1 freetime 1 Query delete from session where 1 Query SELECT User FROM session WHERE 1 Query UPDATE session SET LastAction WHERE 1 Query DELETE FROM session WHERE ID AND 1 Query SELECT * FROM user WHERE ID Журнал запросов не должен быть постоянно активен, так как он разрастается наиболее быстро. Инструкции регистрируются втом порядке, вкаком они поступают на сервер. Этот порядок может отличаться от порядка выполнения инструкций.

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

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

mysqldumpslow at Reading slow query log from Count: 1 Rows=0.0 (0), DELETE FROM WHERE AND User=N Count: 1 (Os) (Os) Rows=1. SELECT FROM comment user WHERE N AND AND N Count: 2 (Os) (Os) Rows=0. delete from session where Журнал обновлений Журнал обновлений применялся в старых версиях MySQL и в настоящее время заменен двоичным журналом.

УСТРАНЕНИЕ ПОСЛЕДСТВИЙ КАТАСТРОФ этой • Проверка и восстановление таблиц • Резервное копирование и восстановление этой главе рассказывается о том, как предотвратить катастрофу и как устранить ее последствия, если все же случилось непоправимое. Рассматриваются вопро сы поиска повреждений в таблицах и их а также методы соз дания резервных копий и последующей работы с ними.

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

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

Существуют два способа проверки и восстановления таблиц. Первый из с помощью специальных инструкций, второй — с помощью утилиты Соот ветствующие инструкции называются CHECK TABLE, REPAIR TABLE и OPTIMIZE TABLE (см. главу 13, "Инструкции SQL"). Они достаточно удобны, поскольку выпол няются в рамках серверного процесса. В этом смысле они ничем не отличаются, к примеру, от инструкции SELECT. Утилита myisamchk обладает рядом дополнитель ных возможностей, которые в ряде ситуаций оказываются весьма удобными. Она бы ла описана в главе 14, "Утилиты командной строки".

454 Глава 25. Устранение последствий катастроф Необходимость проверки таблицы может быть вызвана тем, что утилиты, обра щающиеся к таблице, начинают себя странно вести. Например, вводимые запросы не завершаются или выдаются неожиданные сообщения об ошибках. Если при обраще нии к таблице возвращается номер ошибки, воспользуйтесь утилитой кото рая отображает поясняющее сообщение, соответствующее данному номеру.

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

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

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

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

Таблицы снабжены флагом, указывающим то, изменилось ли содержимое таблицы с момента последней проверки. Инструкция CHECK TABLE пропустит неизме ненные таблицы при наличии ключевого слова CHANGED. В утилите myisamchk ветствующий режим включается с помощью опции Особым образом помечаются также неправильно закрытые таблицы. Чтобы проверить только их, укажите флаг FAST (инструкция CHECK TABLE) или опцию (утилита myisamchk).

По умолчанию утилита myisamchk ищет повреждения только в индексных фай лах. В инструкции CHECK TABLE этот режим включается с помощью флага QUICK. Са ма инструкция CHECK TABLE по умолчанию проверяет не только индексы, но и не правильные ссылки на удаленные записи. В утилите m yisamchk этот режим включа ется с помощью опции Расширенный режим проверки задается флагом EXTEND и опцией В этом случае будут проверяться все индексируемыезначения.

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

Б листинге 25.1 иллюстрируется процедура проверки и восстановления таблицы.

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

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

Инструкция REPAIR TABLE устраняет повреждения в таблице. То же самое делает утилита myisamchk при наличии опции Программа MySQL поддержива ет три типа процедур восстановления: быстрая, обычная и безопасная. В первом слу чае устраняются лишь проблемы с индексами. Во втором случае исправляется также большинство ошибок в табличном файле. В безопасном режиме таблица проверяется строка за строкой, а индексный файл создается заново. Это наиболее длительная процедура.

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

Таблицы с записями переменной длины неизбежно оказываются Это происходит, когда обновляемая запись не помещается в отведенном для нее пространстве. В результате снижается производительность операций выбор ки, поскольку программа вынуждена искать запись в двух и более точках файла. Инст рукция TABLE удаляет из таблицы пустые участки и осуществляет пересор тировку записей. Аналогичные действия выполняет утилита myisamchk при наличии опции Инструкция TABLE также сортирует индексы (соответствующая опция утилиты myisamchk называется Подроб нее о процессе оптимизации рассказывается в главе 26, "Оптимизация".

456 Глава 25. Устранение последствий катастроф Резервное копирование и восстановление Резервная копия — это образ базы данных в конкретный момент времени. К этому образу можно вернуться в случае непредвиденной потери данных. Резервные копии можно создавать сколь угодно часто. Нужно лишь помнить о том, что это достаточно трудоемкий процесс, продолжительность которого зависит от размера базы данных и скоростных характеристик оборудования. В схеме репликации, которая описана в главе 29, "Распределенные базы данных", резервные копии создаются практически мгновенно.

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

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

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

Помните общие правила обращения с резервными копиями. Если они хранятся в той же файловой системе, что и сама база данных, то данные не защищены от сбоев файловой системы. Отсюда правило: копии должны находиться на отдельном носи теле. Храните их на перезаписываемом магнитной ленте или другом жестком диске. Резервные копии могут храниться дома у начальника или администра тора компании. Их можно также пересылать по сети в другую систему. Сегодня, в эпоху Internet, это делать не сложно.

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

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

Какой бы метод ни был выбран, не забудьте защитить таблицы от изменений на время резервного копирования. Если копируются табличные файлы, следует вить сервер. В остальных случаях достаточно поставить блокировки чтения с помо щью инструкций LOCK TABLES и выполнить инструкцию FLUSH TABLES. Последняя необходима для того, чтобы все изменения индексов были записаны в таблицы. На Резервное копирование и восстановление блокировок чтения позволит другим потокам параллельно обращаться к лицам с запросами на выборку.

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

Функции копирования файлов предоставляются операционной системой, поэтому данный способ создания резервных копий является самым быстрым. Таблица dictionary, скопированная в листинге 25.2, содержит более 100000 записей, а файл данных занимает почти 3 Мбайт. Как видите, процедура архивирования такой табли цы заняла менее секунды.

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

Инструкция RESTORE TABLE копирует архивные файлы в каталог базы данных и перестраивает индексы. Таблица не должна существовать на момент восстановления.

В случае необходимости можно удалить ее с помощью инструкции DROP TABLE или же вручную удалить табличные файлы.

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

Если резервные копии создаются вручную, то в архив можно также включить ин дексный файл. В этом случае в процессе восстановления таблицы индексный файл бу дет просто скопирован в каталог базы данных. Тем не менее его всегда можно 458 Глава 25. Устранение последствий катастроф дать с помощью инструкции REPAIR TABLE. Предположим, таблица dictionary бы ла полностью утеряна. Процесс ее восстановления начнем с копирования обратно в каталог базы данных. Создать пустые файлы данных и индексов можно с помощью инструкции TRUNCATE TABLE. Затем необходимо скопировать старый файл данных поверх нового. После этого вводится инструкция REPAIR TABLE. В листин ге 25.4 показано, как программа MySQL обнаруживает расхождение в количестве за писей и перестраивает индексы.

mysql> REPAIR dictionary;

2 rows in set (1 23.41 sec) Для безопасного создания резервных копий лучше пользоваться специальной про граммой, чем делать все вручную. С этой целью в дистрибутив MySQL входит Perl сценарий В листинге 25.5 показано, как с его помощью создаются ко пии таблиц привилегий. Команда позволяет убедиться, что все файлы, в том числе индексные, на месте.

mysqlhotcopy /trap/he 6 tables in 0 seconds.

Flushed tables in 0 seconds.

Copying Copying indices for Unlocked tables.

mysqlhotcopy copied 6 tables (18 files) in 1 second (1 seconds Параметры сценария mysqlhotcopy описывались в главе 14, "Утилиты командной строки". Он блокирует одновременно все таблицы базы данных, после чего очищает табличные буферы и копирует файлы. Сценарий можно запускать во время работы сервера, даже если в этот момент пользователи делают запросы к базе данных. Есте ственно, пока происходит копирование таблиц, пользователям будет запрещено вно сить в них изменения.

Формат табличных файлов понятен только программе MySQL. Если же создать SQL образы таблиц, то их можно будет перенести в другие СУБД. Кроме того, в неко торых ситуациях полезно просматривать такие SQL инструкции. Предположим, к Резервное копирование и восстановление примеру, что потеря данных оставалась незамеченной на протяжении нескольких месяцев. Возможно, пользователи удалили какие то записи и лишь позднее обнаружи ли, что это было сделано неправильно. Нужно восстановить только удаленные запи си, но не известно, когда точно они были удалены. Если резервные копии хранятся в формате SQL, можно просмотреть архивы и поискать, когда последний раз встреча лись требуемые записи. Недостатком такого способа резервного копирования явля ется то, что процедура восстановления занимает много времени, поскольку програм ма MySQL вынуждена выполнять каждую инструкцию из архива.

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

MySQL dump Host: Database: mysql Server version Table structure for table DROP TABLE IF EXISTS db;

CREATE TABLE db Host binary NOT NULL default Db binary NOT NULL default User binary NOT NULL default Select_priv NOT NULL default Insert_priv NOT NULL default Update_priv NOT NULL default Delete_priv NOT NULL default Create_priv NOT NULL default Drop_priv NOT NULL default Grant_priv NOT NULL default References_priv NOT NULL default Index_priv NOT NULL default Alter_priv NOT NULL default PRIMARY KEY KEY User (User) TYPE=MyISAM tt Dumping data for table LOCK TABLES db WRITE;

INSERT INTO db VALUES 460 Глава 25. Устранение последствий катастроф UNLOCK TABLES;

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

Чтобы восстановить данные из такого архива, достаточно выполнить SQL сценарий в интерпретаторе Можно просто перенаправить сценарий на вход этой утилиты или же воспользоваться ее командой source. Интерпр выполнит етатор все инструкции сценария так, как если бы они быливведены в командной строке.

Утилита mysqldump имеет режим создания текстового образа таблицы. В этом режиме для каждой архивируемой таблицы создаются два файла. Один из них имеет расширение и содержит соответствующую инструкцию CREATE TABLE. Второй файл имеет расширение и содержит записи таблицы, причем для разделения полей применяются символы табуляции. В листинге 25.7 показана команда, создаю щая текстовый образ таблицы dictionary в каталоге mysqldump verbose test dictionary Connecting to Retrieving table structure for table Sending SELECT Disconnecting from Для восстановления данных из такого архива необходимо сначала создать табли цу, а затем выполнить инструкцию LOAD DATA INFILE, которая вставит записи в таблицу. Стандартный формат файла, создаваемого утилитой mysqldump, соответст вует тому формату, который по умолчанию распознается инструкцией LOAD DATA INFILE. В листинге 25.8 демонстрируется загрузка данных в таблицу dictionary в среде mysql.

source Query 0 rows affected (0.00 sec) Query OK, 0 rows affected (0.10 sec) Резервное копирование и восстановление LOAD DATA INTO TABLE dictionary;

Query OK, 104237 rows affected (1 27.70 sec) Records: 104237 Deleted: 0 Skipped: 0 Warnings: Создать файл, понимаемый инструкцией LOAD DATA INFILE, позволяет также инструкция SELECT с предложением INTO (листинг 25.9). Схему таблицы необходимо получить другим путем, например с помощью инструкции SHOW CREATE TABLE.

mysql> SELECT * FROM dictionary INTO Query OK, 104237 rows affected (6.42 sec) Один из способов восстановления таблиц заключается в использовании двоичного журнала. Достаточно преобразовать его содержимое в S инструкции и выполнить QL их. Предварительно необходимо заблокировать все таблицы для записи или отклю чить всех клиентов от сервера. Преобразование двоичного журнала осуществляется с помощью утилиты (листинг 25.10). Результаты ее работы нужно напра вить в файл или интерпретатору Обратите внимание: инструкция SET меняет метку текущего времени сеанса, чтобы дата создания таблицы осталась неизменной.

mysqlbinlog short form use SET UPDATE session SET WHERE use freetime;

SET UPDATE session SET LastAction WHERE use freetime;

SET DELETE FROM WHERE AND User=2;

use freetime;

SET INSERT INTO project_view VALUES (2, 2, этой Предварительные действия Тесты производительности Оптимизация проекта Оптимизация приложений Оптимизация запросов Оптимизация инструкций Обслуживание таблиц Настройка конфигурации сервера Перекомпиляция MySQL птимизация — это процесс тонкой настройки системы, направленный на по вышение скорости ее работы или сокращение объема используемой памяти.

В первой части главы объясняется, когда и как нужно оптимизировать базы данных. Бинарные дистрибутивы, доступные на Web узле MySQL, оптимизированы для общего применения. Чтобы адаптировать программу к каким то специфическим требованиям, ее необходимо перекомпилировать. Об этом и пойдет речь во второй части главы.

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

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

Если обнаруживается, что система требует оптимизации, в первую очередь поду майте об обновлении аппаратной части. Это может оказаться самым дешевым вари антом. В 1965 г. Гордон (Gordon Moore) установил, что вычислительные мощно сти удваиваются каждые 18 месяцев. Данное правило называют законом Мура. Но, не смотря на столь стремительный рост производительности, удельная стоимость вычислительных средств неуклонно снижается. Например, центральные процессоры 464 Глава 26. Оптимизация за полтора года удвоят тактовую частоту, хотя стоить будут так же, как и полтора года назад. Таким образом, обновление компьютера может обойтись дешевле, чем опти мизация проекта.

Во вторую очередь стоит подумать об обновлении программного обеспечения.

Основной программный компонент— это операционная система. Известно, что Linux и BSD UNIX позволяют повысить производительность старых компьютеров, превосходя в этом отношении коммерческие операционные системы, такие как Win dows, особенно если бессбойная работа сервера очень важна.

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

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

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

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

Тесты производительности Прежде чем приступать к оптимизации, нужно вооружиться средствами измере ния производительности. Предусмотрительные разработчики MySQL написали груп пу Perl сценариев, для тестирования производительности MySQL и других СУБД. Эти сценарии расположены в каталоге исходного дистри бутива. В подкаталоге Results находятся результаты множества тестов существую щих систем, которые можно сравнить с собственными оценками.

В сценариях используется демонстрационная база данных, в которой выполняется восемь различных тестов. Эта база данных называется и инсталлируется вместе с MySQL. Сценарий run all tests запускает все тесты последовательно. При нали чии опции результаты работы сценария будут сохранены в каталоге output для последующего просмотра. Ниже приведена команда, запускающая тесты из ката лога sql bench.

Для работы этого сценария необходимо наличие в системе интерпретатора Perl и модуля DBI.

Тесты производительности Для экспериментов я использую старый компьютер Pentium с частотой работающий под управлением Linux. Несмотря на слабую вычислительную мощность, программа MySQL демонстрирует нанем вполне приемлемую производи тельность. Кроме того, ограниченные возможности системы позволяют быстро вы являть неэффективные программные решения. Результаты тестов, полученные на этом компьютере, показаны в листинге Несложно убедиться, что моя система работает примерно в 10 раз медленнее, чем самая медленная из систем, результаты тестов которых имеются в каталоге Results. Если бы такую производительность продемонстрировал рабочий сервер, нужно было бы немедленно обновить его аппа ратную часть.

The result logs which were found and the options:

1 MySQL 3.23. The results per operation: I 466 Глава 26. Оптимизация Тесты производительности Сценарий compare results суммирует и сравнивает результаты тестов. В лис тинге приведен лишь один набор результатов. В действительности я немного со кратил выходные данные, удалив ряд малозначащих пояснений. В первом блоке чисел указано время выполнения каждого из восьми тестов в секундах. Во втором блоке отображается статистика отдельных операций по всем тестам. Числа со знаком это приблизительные оценки, полученные для тестов, время выполнения которых превысило максимум.

Результаты тестов, предоставляемые разработчиками MySQL, можно использо вать для выбора аппаратной платформы и операционной системы. На Web узле MySQL (unvw.mysql.com/information/benchmarks.html) постоянно публикуются обновляе мые результаты и графики сравнения показателей MySQL с показателями других СУБД, работающих на идентичном оборудовании. Приводятся также данные, касаю щиеся работы MySQL на разных платформах.

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

Для оценки производительности запросов необходимо воспользоваться инструкцией EXPLAIN (см. главу 13, "Инструкции SQL"). Эта инструкция, помимо всего прочего, сообщает о том, сколько записей будет прочитано при выполнении заданной инст рукции SELECT. Каждая строка результатов соответствует одной исходной таблице, а порядок строк совпадает с порядком обращения к таблицам. Сообщаемое число запи сей может быть приблизительным, но погрешность очень мала. Произведение счет чиков записей является грубым критерием производительности запроса. Чем меньше это произведение, тем быстрее выполняется запрос.

Представим себе, к примеру, объединение таблицы, содержащей 15000 слов, с таблицей, содержащей 100000 слов. В худшем случае программе MySQL придется просмотреть все записи обеих таблиц. Сначала выбирается первая запись первой таблицы, а затем начинается просмотр записей второй таблицы до тех пор, пока не будет найдено совпадение. Умножив 15000 на 100000, получим миллиарда опера ций чтения. На практике это числооказывается немного меньшим, но и его доста точно, чтобы получить представление о скорости запроса. Далее в главе будет расска зываться о том, как с помощью индексов уменьшить количество записей, читаемых в процессе объединения таблиц.

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

468 Глава 26. Оптимизация Оптимизация проекта Давайте вспомним то, о чем говорилось в главе 8, "Нормализация". Нормализация — это такой метод оптимизации базы данных, при котором избыточность хранящейся в ней информации оказывается минимальной. Следовательно, уменьшается время, за трачиваемое приложением на поддержание целостности базы данных. Нормализация достигается за счет повышения объема работы, выполняемой сервером, так как уве личивается число таблиц и серверу приходится чаще создавать их объединения. В процессе в базу данных вносят некоторую избыточность, для того чтобы сократить объем работы по извлечению информации.

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

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

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

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

Реляционные базы данных хорошо работают с типизированными значениями фиксированного размера. В MySQL поддерживаются типы переменной длины, на пример BLOB и TEXT, но управлять ими сложнее. Такого рода информацию лучше хранить в файлах, а в базе данных достаточно запоминать путевые имена этих файлов в столбцах типа CHAR. Если база данных используется в Web приложениях, помните о том, что у Web сервера есть загружаемых файлов изображений и аудио клипов, поэтому он будет работать с такими файлами быстрее, чем MySQL.

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

Монти рассказал мне правило определения того, когда следует исполь зовать столбцы типа VARCHAR, а когда — CHAR. Если в таблице есть столбцы типа BLOB или TEXT, то предпочтение отдается типу VARCHAR, потому что все записи таблицы будут динамическими. То же самое справедливо для случая, когда средняя размер ность значений столбца не превышает половины его размерности. Например, стол бец типа VARCHAR средняя размерность которого равна символам, определен правильно. Если же средняя размерность превышает 40 символов, нужно поменять Оптимизация приложений тип столбца на CHAR Данное правило направлено на оптимизацию скорости ра боты с таблицами. Когда более важным фактором является экономия дискового про странства, то в большинстве случаев следует пользоваться типом VARCHAR.

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

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

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

Многие типы данных допускают регулирование своей размерности. Например, в столбце типа CHAR может храниться столько уникальных значений, что приводить его к типу ENUM нет никакого смысла, и все равно формальная размерность оказыва ется избыточной. То же самое касается типа INT, у которого существуют более "короткие" эквиваленты: и TINYINT. Но не забудьте учесть бу дущее пополнение таблицы. Например, если в таблице 16000 записей, то для первич ного ключа вполне подойдет тип SMALLINT. Если же предполагается, что в таблице будет более 65535 записей, следует остановиться на типе INT.

Обратите внимание на столбцы, в которых не могут присутствовать значения NULL. Для экономии места такие столбцы нужно объявлять со спецификатором NOT NULL. Числовые столбцы, в которых не могут храниться отрицательные долж ны иметь спецификатор UNSIGNED.

Оптимизация приложений Подключение к базе данных MySQL п роисходит относительно быстро в сравне нии с другими СУБД, но это время можно еще уменьшить за счет кэширования соеди нений. Требуется лишь прикладная среда, позволяющая хранить идентификаторы соединений в памяти во время работы сервера. Например, модуль непрерывно работает на Web сервере. Он поддерживает функцию которая создает постоянные соединения. Получив запрос на подключение к серверу, модуль РНР попытается использовать существующее если это возможно. В про токолах JDBC и ODBC тоже применяется технология кэширования соединений. Она особенно удобна, когда приложение создает большое число соединений за короткий промежуток времени.

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

470 Глава 26. Оптимизация Приложение может дотировать информацию, извлекаемую из базы данных. Это выгодно, если данные меняются нечасто. Когда изменение данных все же происхо дит, приложение запрашивает принудительную очистку буфера. Предположим, что в Internet магазине имеется каталог продаваемых товаров. Этот каталог пополняется или обновляется раз в неделю, а то и меньше. Когда приложение отправляет клиенту с описанием товара, оно вполне может взять информацию из кэша.

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

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

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

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

Разрешается создавать индекс, охватывающий несколько столбцов. Программа MySQL может работать с частями индекса, но они должны просматриваться строго слева направо. Например, если индекс включает столбцы имени и фамилии, то при обращении к первому столбцу индекс будет использован, а ко нет (при ус что перед этим не было обращения к первому столбцу). Это правило приме нимо и к символам индексируемого столбца, содержащего текстовые данные (тип CHAR, VARCHAR или BLOB). Когда в предложении WHERE присутствует оператор LIKE, индекс лишь в том случае, если шаблон сравнения содержит все лите ральные символы слева, а справа. Так, шаблон разрешает ис пользование индекса, а шаблон — нет.

В листинге 26.2 приведены инструкции, создающие две таблицы. Таблица word содержать 14346 записей, а таблица dictionary— 104237. В первую таблицу слова заносятся пользователями, а вторая таблица содержит список известных про грамме слов. Пользователи часто вводят несуществующие слова. Запрос, анализируе мый в листинге 26.3, предназначен для выяснения количества распознанных слов.

Условию отбора соответствуют записей.

mysql> EXPLAIN SELECT word.word, dictionary.word -> FROM word LEFT JOIN dictionary -> ON word.word=dictionary.word -> WHERE word.class = '_VERBO' \G *************************** 1.row *************************** table: word type: ALL possible_keys: NULL key: NULL key_len: NULL ref: NULL rows: Extra: where used table: dictionary type: ALL possible_keys: NULL key: NULL key_len: NULL 472 Глава 26. Оптимизация NULL rows: 2 rows in set (0.00 sec) В запросе участвуют три столбца: столбцы word и таблицы word и столбец word таблицы dictionary. Известно, что тестовому условию отбора соответствуют записей таблицы word, поэтому наша задача состоит в том, чтобы сократить диа пазон сканирования первой таблицы до соответствующего уровня. Для этого необхо димо создать индекс по столбцу class. Сначала я планировал включить в индекс только упомянутый столбец, но потом подумал о других запросах, которые приходит ся направлять таким таблицам. Я, например, часто создаю отчет, в который включа ется все содержимое таблицы, отсортированное сначала по классам, а затем — по сло вам. Разумнее будет включить в индекс сразу два столбца (листинг 26.4).

ALTER TABLE word ADD INDEX (class, word) Теперь инструкция EXPLAIN выдает другие результаты (листинг 26.5). В поле key_len сообщается о что индекс охватывает 16 символов столбца class. По оценке программы MySQL, ей придется просмотреть 1517 записей, хотя мы знаем, mysql> EXPLAIN SELECT FROM word LEFT JOIN dictionary ON WHERE \G table: word type: ref class key: class key_len: ref: const rows: Extra: where used;

Using index table: dictionary ALL NULL key: NULL key_len: NULL ref: NULL rows: 2 rows in set (0.00 sec) Оптимизация инструкций Итак, появление индекса привело к сокращению диапазона сканирования в 15 раз, но инструкция все ее вынуждена просматривать 45 миллионов записей. Осталось еще учесть столбцы word в обеих таблицах. Разберемся сначала с таблицей word.

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

Теперь перейдем к таблице dictionary. Пока что SELECT вынуждена сканировать ее целиком. Добавление индекса к столбцу word позволит программе сразу же находить нужную запись (листинг ALTER TABLE dictionary ADD INDEX (word) Эффект этого действия продемонстрирован в листинге 26.7. Как видите, количе ство просматриваемых записей таблицы dictionary сократилось до одной!

EXPLAIN SELECT FROM word LEFT JOIN dictionary ON WHERE \G table: word type:

class key: class key_len: ref: const rows: Extra: where used;

Using index table: dictionary type: ref word key: word key_len: ref:

Extra: Using index 2 rows in set (0.26 sec) Оптимизация инструкций От оптимизации больше всего выигрывают запросы на выборку, но существуют также методики повышения эффективности других инструкций, в частности INSERT.

Можно избежать затрат времени на анализ инструкции, если воспользоваться 474 Глава 26. Оптимизация значений по умолчанию. Вместо того чтобы указывать значения всех столбцов, задайте лишь те из них, которые отличаются от стандартных установок, а остальное пусть сделает MySQL. Ска занное иллюстрирует листинг 26.8, в котором по казаны определение таблицы и инструкция CREATE TABLE address ID NOT NULL AUTO_INCREMENT, default NULL, Name_First default NULL, Name_Middle default NULL, Name_Last NOT NULL default default NULL, Company default NULL, default NULL, Street2 default NULL, default NULL, City NOT NULL default NOT NULL default NOT NULL default default NULL, default NULL, Phone2 default NULL, Fax default NULL, Email NOT NULL default PRIMARY KEY INSERT INTO address VALUES По умолчанию операции записи имеют приоритет над операциями чтения, но программа MySQL не прервет выполнение инструкции SELECT, если в очереди вдруг появится инструкция INSERT. Последняя окажется заблокированной до тех пор, пока инструкция SELECT не завершится. У инструкции INSERT есть также специальный флаг DELAYED, при наличии которого инструкция помещается в очередь без блоки рования клиентского приложения, что повышает его оперативность.

Если есть несколько записей, предназначенных для вставки в та блицу, воспользуй тесь многострочной инструкцией INSERT. Еще быстрее работает инструкция LOAD DATA INFILE. Для полной очистки таблицы лучше вызывать инструкцию TRUNCATE TABLE, а не DELETE. В случае программа MySQL удалит и снова создаст таблич ный файл, вместо того чтобы удалять записи одна за другой.

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

Обслуживание таблиц Обслуживание таблиц Можно ускорить выполнение запросов, если хранить таблицы и индексы в упоря доченном виде. Инструкция TABLE улучшает таблицу тремя способами. Во первых, она устраняет пустые промежутки, оставшиеся после удаления записей. Для таблиц это означает возможность одновременного выполнения инструкций INSERT и SELECT. Во вторых, она соединяет распределенные фрагменты таблиц с динамическими записями. И наконец, она сортирует индексы.

Инструкция ALTER TABLE позволяет отсортировать записи таблицы. Это тоже собствует ускорению некоторых запросов, хотя и не устраняет потребность в индексах.

Если таблица меняется редко, а дисковое пространство ограничено, имеет смысл сжать таблицу с помощью утилиты (см. главу 14, "Утилиты командной строки"). После этого таблица будет доступна только для чтения. Ее индексы необхо димо перестроить, вызвав утилиту Данная методика позволяет умень шить размер таблицы на 40 70%, в зависимости от формата ее содержимого. В лис тинге 26.9 показан процесс сжатия таблицы, содержащей названия штатов США.

state Compressing (50 records) Calculating statistics Compressing file 32.42% Remember to run myisamchk on compressed tables myisamchk rq state check key check record delete chain recovering (with sort) Data records: Fixing index Fixing Настройка конфигурации сервера Когда речь заходит об объеме оперативной памяти сервера, совет всегда один: чем тем лучше. Увеличение объема памяти способствует ускорению работы программы MySQL, так как в оперативной памяти она хранит свои временные табли цы и буферы записей. В подкаталоге support files дистрибутива содержатся разцы конфигурационных файлов с различными вариантами настроек, касающихся использования памяти. Выберите тот вариант, который соответствует исходным па раметрам сервера. Поработав с сервером какое то время, можно будет оценить, какие из настроек требуют корректировки.

В листинге 26.10 показана конфигурация сервера, располагающего как минимум 1 Гбайт ОЗУ, четырьмя жесткими дисками и четырьмя центральными процессорами.

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

476 Глава 26. Оптимизация set variable set variable set variable table_cache= set variable set variable set variable thread_cache_size= set variable thread_concurrency= set variable log bin server id Таблицы set variable bdb_cache_size=384M set variable Таблицы /disk3/ /disk4/ /disk4/ set variable set variable set variable innodb_log_file_size=5M set variable innodb_log_archive= set variable set variable set variable set variable Когда сервер проработает какое то время, выполните инструкцию SHOW STATUS, чтобы узнать его производительность. Сравните значения показателей Key_reads и Их соотношение будет очень низким, если программа MySQL часто пользуется индексным буфером. В случае необходимости попытайтесь повы сить размер буфера.

Проследите изменение показателя Open_tables, сравнивая его со значением серверной переменной table_cache, которое можно узнать с помощью инструкции SHOW VARIABLES. Когда табличный буфер заполняется, программа MySQL вынужде на закрывать одни таблицы, чтобы открывать другие. Показатель Opened_tables отражает число таблиц, открывавшихся с момента запуска сервера. Сравните его с общим числом запросов (показатель Questions). Чем больше будет размер таблич ного буфера, тем реже придется открывать и закрывать таблицы.

Серверная переменная thread_cache_size задает размер кэша потоков. Как правило, на каждый процессордолжно приходиться два потока. Сравните показатели и Connections, определить, как часто серверу приходи лось повторно использовать потоки.

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

Перекомпиляция MySQL Команда разработчиков MySQL прилагает огромные усилия для оптимизации ис полняемых файлов программы. Лучше всего пользоваться бинарными дистрибутивами, которые доступны на MySQL. Вряд ли вам удастся получить более качествен ный исполняемый файл. Например, в дистрибутивы Linux зачастую включаются неста бильные версии компиляторов и библиотек. Разработчики MySQL всегда применяют самые стабильные версии в сочетании с оптимальными опциями компиляции.

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

Еще одна желание поэкспериментировать с различными библиотеками.

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

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

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

Нужен также компилятор языка C++. Вполне подойдет какая нибудь включая He забудьте и об утилите make.

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

CXX=gcc \ \ \ \ В табл. 26.1 перечислены параметры сценария Аналогичную мацию можно получить, вызвав сценарий с опцией Если нужно включить поддержку таблиц Berkeley DB или не забудьте указать соответствующие 478 Глава 26. Оптимизация В исходные дистрибутивы MySQL входят все необходимые для этого файлы, по этому путь к библиотекам Berkeley DB задается только в том случае, когда требуется использовать их альтернативные версии.

Общая результаты файле Вывести список опций He создавать выходные файлы He отображать сообщения Отобразить номер версии утилиты которая создала данный сценарий Имена файлов и каталогов Помещать архитектурно независимые файлы в каталог префикс (по умолча нию Помещать архитектурн о зависимые файлы в каталог (по умолча нию — префикс) Помещать пользовательские испол няемые файлы в каталог (по нию — /bin) Помещать административные испол няемые файлы в каталог (по умолча нию — префикс Помещать исполняемые файлы про грамм в каталог (по умолчанию — Помещать архитектурно независимые данные, доступные только для чтения, в каталог (по умолчанию — префикс/ share) Помещать системные данные, доступ ные только для чтения, в (по умолчанию — префикс/ etc) Перекомпиляция MySQL Имена и каталогов Помещать модифицируемые архитек турно независимые данные в каталог (по умолчанию — префикс/ com) Помещать модифицируемые систем ные данные в каталог (по умолчанию — Помещать объектные библиотеки в талог (по умолчанию — Помещать файлы заголовков в каталог (по умолчанию — include) Помещать файлы заголовков, не предна значенные для компиляторов в (по Помещать документацию системы Info в каталог (по умолчанию — Помещать документацию системы Man в каталог (по умолчанию — Искать исходные файлы в каталоге (сначала — в каталоге сценария) Добавлять префикс к именам инсталли рованных программ Добавлять суффикс к именам инсталли рованных программ program transform Запускать программу для инсталлированных программ зла Рабочий узел (по умолчанию guessed) узел) Свойства и пакеты Не включать свойство (то же, что 480 Глава 26. Оптимизация Свойства и пакеты Включить свойство умолчанию — yes) Использовать пакет (по умолчанию — yes) Не использовать пакет (то же, что Искать включаемые файлы X Window в каталоге Искать библиотеки X Window в каталоге Дополнительные возможности Разрешить правила и зависимости ути литы make, лишние (а ин огда ные) для обычного инсталлятора Создавать совместно используемые библиотеки Создавать статические библиотеки Оптимизировать установки для быст рой инсталляции Предполагать, что компилятор языка С использует (по умолчанию отключена) Избегать блокировок (могут помешать параллельной работе потоков компи лятора) Подключать библиотеку и другие стандартные библиотеки, располо женные в нестандартном каталоге.

Изначально эта опция появилась, что бы компилятор мог подключать биб лиотеку версии 2.2, не требуя от пользователей обновлять стандартную библиотеку libc Добавлять идентификатор сервера в строку версии Перекомпиляция MySQL Дополнительные возможности Использовать библиотеку Использовать Использовать указанную потоковую библиотеку, а не которая автомати чески обнаруживается сценарием Использовать указанную библиотеку curses, а не ту,которая автоматиче ски обнаруживается сценарием Использовать указанную библиотеку а не ту, которая автоматически обнаруживается сценарием Компилировать клиент с поддержкой потоков Использовать ассемблерные версии некоторых строковых функций, если это возможно Включить поддержку RAID дисков Использовать указанный параметр должен представлять собой абсолютное путевое имя Использовать заданный порт для висов MySQL (по умолчанию — 3306) Запускать демон от имени Отключить поддержку больших файлов Компилировать программу с поддержкой библиотеки He включать в программу код отладки Использовать дополнительные пара метры компоновки демона Использовать дополнительные пара метры компоновки клиентов 482 Глава 26. Оптимизация возможности Стараться использовать меньше памя ти на этапе компиляции Выдавать комментарии о среде компи ляции Создавать только клиентскую программу He создавать документацию He создавать набор тестов производи тельности Использовать системную версию биб лиотеки а не ту, что входит в дистрибутив Сделать указанный набор символов основным (по умолчанию — Использовать дополнительные набо ры символов помимо основного;

аргу мент список может содержать перечень наборов символов, ключевые слова complex (включать все наборы симво лов, которые нельзя загрузить дина мически) или all (включать все набо ры символов) Использовать библиотеку Berkeley DB, расположенную в указанномкаталоге Искать файлы заголовков Berkeley DB каталоге Искать библиотечные файлы Berkeley DB в каталоге Использовать библиотеку Использовать библиотеку Gemini, рас положенную в указанномкаталоге Когда сценарий configure окончит запустите утилиту make, чтобы создать исполняемый файл. После этого необходимо выполнить команду make которая поместит созданные файлы в соответствующие каталоги. Подроб нее об этом рассказывалось в главе 2, "Инсталляция MySQL".

БЕЗОПАСНОСТЬ В этой главе.

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

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

Схема привилегий В списке управления доступом (Access Control List, ACL) указывается, какие инструк ции разрешено выполнять тем или иным пользователям. Такой список можно связать с пользователем, узлом, базой данных, таблицей или столбцом. Программа MySQL сверя ет каждое обращение к базе данных с имеющимися списками управления доступом и определяет, есть ли у пользователя право выполнить запрашиваемое действие.

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

Пользовательские имена и пароли могут быть длиной до 16 символов. Пароль раз решается оставлять пустым. Это самый низкий уровень безопасности. Он допустим только в том когда доступ ограничивается по каким то другим критериям, на пример адресу узла.

Глава 27. Безопасность Перечень привилегий хранится в базе данных Сценарий который запускается в ходе инсталляции программы, создает в этой базе данных пять лиц с описаниями привилегий (табл.

Таблица Содержимое Привилегии отдельных столбцов db Привилегии всей базы данных host Привилегии всех пользователей того или иного узла Привилегии отдельных таблиц user Глобальные привилегии В таблице описываются глобальные права доступа и хранятся пользователь ские пароли. Алгоритм шифрования паролей отличается от того, который применя ется операционной системой. Пароль можно создать с помощью функции PASSWORD (см. главу 12, "Встроенные функции") или путем прямого изменения таблицы user, но удобнее всего это делать с помощью инструкции GRANT.

При попытке подключения к серверу программа MySQL обращается к таблице user и проверяет, имеет ли пользователь право на подключение. Имя, пароль и адрес узла пользователя должны соответствовать как минимум одной записи таблицы. Если этого не происходит, программа отказывает пользователю в запросе. Но даже когда подключение легитимно, пользователю может быть разрешено выполнять лишь ог раниченный набор SQL инструкций. Права доступа к данным контролируются ос тальными четырьмя таблицами базы mysql. Следует, правда, отметить, что любому зарегистрированному пользователю разрешено вводить инструкции SELECT с лите ралами в списке возвращаемых столбцов, например SELECT NOW В листинге показаны определения всех пяти таблиц привилегий.

CREATE TABLE Host BINARY NOT NULL DEFAULT Db BINARY NOT NULL DEFAULT User BINARY NOT NULL DEFAULT Table_name BINARY NOT NULL DEFAULT BINARY NOT NULL DEFAULT NOT NULL, NOT NULL DEFAULT PRIMARY KEY (Host, Db, User, CREATE TABLE db Host BINARY NOT NULL Db BINARY NOT NULL DEFAULT User BINARY NOT NULL DEFAULT Select_priv NOT NULL DEFAULT NOT NULL DEFAULT Update_priv NOT NULL DEFAULT NOT NULL DEFAULT Create_priv NOT NULL DEFAULT Drop_priv NOT NULL DEFAULT Grant_priv NOT NULL DEFAULT References_priv ENUM('N1, NOT NULL DEFAULT Index_priv NOT NULL DEFAULT NOT NULL DEFAULT PRIMARY KEY (Host, KEY User (User) TYPE=MyISAM CREATE TABLE host Host BINARY NOT NULL DEFAULT Db BINARY NOT NULL DEFAULT Select_priv NOT NULL DEFAULT Insert_priv NOT NULL DEFAULT NOT NULL DEFAULT Delete_priv NOT NULL DEFAULT NOT NULL DEFAULT Drop_priv NOT NULL DEFAULT Grant_priv NOT NULL DEFAULT References_priv NOT NULL DEFAULT Index_priv NOT NULL DEFAULT Alter_priv NOT NULL DEFAULT PRIMARY KEY (Host, Db) TYPE=MyISAM COMMENT='Host privileges;

Merged with database privileges';

CREATE TABLE tables_priv Host BINARY NOT NULL DEFAULT Db BINARY NOT NULL DEFAULT User BINARY NOT NULL DEFAULT BINARY NOT NULL DEFAULT Grantor NOT NULL DEFAULT NOT NULL, Table_priv NOT NULL DEFAULT NOT NULL DEFAULT PRIMARY KEY (Host, Db, User, KEY Grantor (Grantor) CREATE TABLE user Host BINARY NOT NULL DEFAULT User BINARY NOT NULL DEFAULT 488 Глава 27. Безопасность Password BINARY NOT NULL DEFAULT Select_priv NOT NULL DEFAULT Insert_priv NOT NULL DEFAULT Update_priv ENUM('N', NOT NULL DEFAULT Delete_priv NOT NULL DEFAULT Create_priv NOT NULL DEFAULT Drop_priv ENUM('N', NOT NULL DEFAULT NOT NULL DEFAULT ENUM('N', NOT NULL DEFAULT Process_priv ENUM('N', NOT NULL DEFAULT File_priv ENUM('N', NOT NULL DEFAULT Grant_priv ENUM('N', NOT NULL DEFAULT References_priv ENUM('N', NOT NULL DEFAULT Index_priv ENUM('N', NOT NULL DEFAULT Alter_priv ENUM('N', NOT NULL DEFAULT PRIMARY KEY (Host, User) and global За каждым пользователем каждого узла в таблице user закреплен свой набор гий, заданных в виде перечислений со значениями В столбце Host содержится IP адрес либо доменное имя Разрешается использовать метасимволы % и для задания диапазона адресов. Например, выражение % com Схема привилегий именем пользователя Поскольку подобный выбор не всегда очевиден, лучше избегать пустых имен пользователей.

Таблицы и host совместноконтролируют доступ к базам данных. Подобно лице в таблице db не допускаются имена пользователей с метасимволами. При выполнении операций сравнения программа MySQL сортирует записи этой таблицы в таком порядке: имя узла, имя базы данных, имя пользователя. Другими словами, сначала выбирается наиболее точное имя узла, наиболее точное имя базы данных, а наиболее точное имя пользователя. Записи таблицы host сортиру ются сначала по имени потом — по имени базы данных.

Таблицы и tables_priv допускают наличие метасимволов в це Host, но не вдругих столбцах. Поэтому, чтобы предоставить пользователю права доступа трем столбцам таблицы, нужно задать три записи в таблице В табл. 27.2 перечислены столбцы привилегий, встречающиеся в таблицах. Смысл каждого из них определяется таблицей, в которой он присутствует. Запись таблицы db применима ко всем таблицам базы данных. Привилегии, заданные в таблице user, являются глобальными. Есть привилегии, которые определены только на глобальном уровне. Например, право перезагрузки позволяет пользователю очищать кэш буферы, совместно используемые всеми соединениями и базами данных.

Описание Пользователь может вводить инструкцию ALTER TABLE Create_priv Пользователь может создавать таблицы и базы данных Delete_priv Пользователь может вводить инс трукцию DELETE Пользователь может удалять таблицы и базы данных Пользователь может обращаться к файлам локальной файло вой системы Grant_priv Пользователь может передавать свои привилегии другим пользователям \ Пользователь может добавлять или удалять индексы Insert_priv Пользователь может вводить инструкцию INSERT Process_priv Пользователь может просматривать список соединений и удалять соединения Reload_priv Пользователь может очищать буферы Соответствующая привилегия еще не реализована Select_priv Пользователь может создавать запросы к таблицам (инструкция SELECT) Пользователь может останавливать сервер Update_priv Пользователь может вводить инструкцию UPDATE 490 Глава 27. Безопасность Названия привил егий в большинстве своем соответствуют названиям инструкций поэтому легко какие права получают пользовател и благодаря той или иной привилегии. Привилегия Alter позволяет пользователю менять определения таблиц.

Привилегия Create дает возможность, в зависимости от контекста, создавать таблицы или базы данных. Привилегия Delete разрешает удалять записи таблиц, а привилегия сами таблицы или базы данных. Привилегия Index позволяет создавать и уда лять индексы, привилегия Insert — вставлять записи в таблицы, а привилегии Select и Update — выполнять инструкции SELECT и UPDATE соответственно.

Привилегия разрешает пользователям выполнять инструкцию LOAD DATA INFILE, а также инструкцию SELECT с предложением INTO OUTFILE. Она определя ет лишь возможность чтения и записи файлов на сервере. Естественно, помимо этого пользователь должен иметь право чтения и записи самой таблицы. Файловые опера ции осуществляются от имени пользователя, запустившего демон Операци онная система может налагать на него свои ограничения, чтобы демон не повредил важные системные файлы.

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

Привилегия Process дает пользователю возможность просматривать список единений с помощью инструкции SHOW PROCESSLIST и удалять любое соединение при помощи инструкции KILL. Подобной привилегией владеют только администра торы, имеющие доступ к утилите Привилегия Reload позволяет пользователю вводить любую из инструкций FLUSH, описанных в главе 13, "Инструкции SQL". Обычно кэш буферы не требуют очистки, за исключением ряда случаев. При непосредственном редактировании таб личных файлов необходимо очистить табличный буфер. Если таблицы привилегий меняются в обход инструкций GRANT и REVOKE, то нужно очистить буфер привиле гий. Рядовым пользователям данная привилегия не нужна.

Привилегия Shutdown разрешает пользователю завершать работу демона mysqld.

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

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

В данном случае программа выбирает только те привилегии, которые определены в обеих таблицах. Например, если в таблице db пользователю выдается привилегия Update, а в таблице host нет, программа не разрешит пользователю обновлять все таблицы базы данных.

Задание привилегий Если искомые привилегии в таблицах и host отсутствуют, программа проверя ет таблицу table В ней определены привилегии доступа к отдельным табли цам. В последнюю очередь проверяется таблица column и там ничего не найдено, пользовательский запрос отклоняется.

Pages:     | 1 |   ...   | 3 | 4 || 6 | 7 |



© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.