или isamchk для анализа распределения значений ключа. Для таблиц MylSAM необходимо воспользоваться утилитой myisamchkia для таблиц ISAM - утилитой isamchk. Для анализа ключей необходимо иметь право на регистрацию на узле сервера MySQlJ и право доступа к табличным файлам.

Для проверки работы оптимизатора пользуйтесь ключевым словом EXPLAIN. Проверьте задействованные в запросе индексы, чтобы быстро исключить из рассмотрения ненужные строки. Если нет, можно попробовать объединения типа straight join для того, чтобы обеспечить определенный порядок объединения таблиц. Просмотрите, как работают различные варианты запроса. Возможно, что лучше будет индексами вовсе не пользоваться.

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

Подавление оптимизации

Как это ни сфанно, но иногда приходится подавлять механизм оптимизации СУБД MySQL. Это может пофебоваться при следующих обстоятельствах.

Необходимость замедления процесса удаления содержимого таблиц.

При необходимости полного удаления содержимого таблиц самым удобным способом будет удаление всего содержимого таблицы с помощью оператора delete без предложения where:

DELETE FROM tbl name

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

MySQL может вернуть количество сфок в таблице, равное О, в то время как в таблице записи есть. В большинстве случаев это

не имеет значения (правда, это может сильно озадачить в том случае, если такого результата не ждешь), но иногда это может оказаться просто неприемлемым.

Если таблица имеет в своем составе столбец AUTO INCREMENT, его счетчик сбрасывается и устанавливается в 1. Это справедливо даже для СУБД MySQL версии 3.23, в которой обработка параметра AUTO iNCREMENT Претерпела некоторые изменения. Эти изменения описаны в главе 2, Работа с данными в MySQL , в разделе Обработка последовательностей .

В операторе DELETE оптимизацию оператора можно отключить, прибегнув к предложению WHERE 1>0:

delete from tbl name where 1 > О

Это заставит СУБД MySQL произвести построчное удаление. Такой запрос вьтолнится значительно медленней, но вернет реальное количество удаленных строк. Кроме того, это поможет сохранить существующую последовательную нумерацию auto INCREMent (только для таблиц в формате MylSAM). К сожалению, для таблиц, хранящихся в формате ISAM, последовательность все равно сбрасьшается в L

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

update iny tbl set кеу со1 = кеу со1+1 where кеу со1 > 0;

Решением этой проблемы будет использование столбца keyed в предложении WHERE. Это отключит использование индекса:

update my tbl set кеу со1 = кеу со1+1 where кеу со1+0 > 0;

Есть и другое решение. Установите у себя СУБД MySQL версии 3.23.2 или выше, в которой эта проблема уже решена.

Производите поиск результатов в произвольном порядке. Для сортировки получаемых результатов в случайном порядке в версии 3.23.3 была добавлена сортировка по функции ORDER BY RAND (). Другим методом, применимым к старым версиям СУБД MySQL, является выборка столбца, содержащего случайные числа с последующей сортировкой по этим числам. Но если написать запрос следующего вида, оптимизатор сведет все ваши усилия на нет:

select ..., rand() as rand col from ... order by rand col

Суть проблемы, затронутой здесь, заключается в том, что оптимизатор видит вызов функции, считает, что значение столбца является константой и оптимизирует предложение ORDER BY прямо в за-

просе! Можно обмануть оптимизатор, указав столбец из таблицы * функции. Например, если в вашей таблице есть столбец age, мо>№-но написать такой запрос: 1

SELECT age*0+RAND{) as rand col FROM ... ORDER BY rand col (

Подавление сортировки при объединении таблиш>1 оптимизатором. щ\я

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

Выбор типа столбцов и эффективность запросов

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

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

ш Не пользуйтесь длинными столбцами, когда вполне достаточно коротких. Не делайте столбцы типа CHAR необоснованно длинными. Если самая длинная строка, хранящаяся в столбце будет иметь длину 40 символов, то совсем необязательно объявлять его как CHAR (255). Размеры таблицы можно уменьшить, если вместо типа BIGINT воспользоваться типом MEDIUMINT. Это уменьшит количество операций ввода-вывода, при вычислениях значения будут обрабатываться быстрее.

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

этом раздеае под типом BLOB подразумевается сразу два типа BLOB и TEXT.

240 Часть I. Использование СУБД MySQL