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

Пользуйтесь функцией PROCEDURE ANALYSE( ). С помощью функции procedure analyse () МОЖНО просмофеть Характеристики столбцов в таблицах.

SELECT * FROM tbl name PROCEDURE ANALYSE() SELECT * FROM tbl narae PROCEDURE ANALYSE{16,256)

Первый оператор дает предложения по оптимальным типам для всех столбцов таблицы tbl name. Второй пример сооощас! функции procedure analyse {) не предлагать тип enum, содержащий более 16 значений или длина которых требует не более 256 байт (при желании значения можно изменить). Без таких ограничений выводимый результат будет слишком фомоздким. В таких случаях объявления enum очень трудно читаются.

На основании результата работы функции procedure analyse () можно судить об эффективности табличной структуры. Изменить сфуктуру таблиц можно с помощью стандартного оператора alter

table.

Храните данные в упакованном виде в типе BLOB. Использование типа blob для хранения данных позволяет получать данные за одну выборку. Это удобно для хранения данных, которые зафудни-тельно хранить в стандартной табличной структуре. В описании оператора alter table в главе 3, Синтаксис и использование языка SQL , был приведен пример, в котором таблица использовалась для хранения результатов из анкеты, созданной на базе Web-узла. В том примере было показано, как с помощью оператора alter table столбцы добав.лялись В таблицу, когда пофебова-лось добавить новые вопросы в анкету.

Еще один подход к решению этой проблемы - создание приложения, основной функцией которого является преобразование данньк, заносимых в Web-анкету, в некое подобие сфуктуры данных, а затем вставка ее в один столбец типа blob. Это добавит работы по кодировке данных (и раскодировке данных при последующей выборке данных из таблицы), но упрощает структуру данных и избавляет от необходимости изменять сфуктуру таблиц всякий раз, когда изме-неняется сфуктура анкеты.

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

Пользуйтесь параметром OPTIMIZE TABLE для таблиц, которые подвержены фрагментации. Таблицы, над которыми часто производится операция модификации (особенно имеющие в своей структуре записи переменной длины) часто подвержены фрагментации. Явление фрагментации само по себе нежелательно потому, что при этом на диске формируется больщое количество неиспользуемых блоков. Это вызывает излищнюю потерю времени так, как При выборке требуется считывание дополнительного количества блоков, что в итоге вызывает падение производительности. Это имеет место и для других типов столбцов, но особенно ощутимо для столбцов типа BLOB, потому что они имеют большие размеры. Постоянное использование параметра OPTIMIZE TABLE позволяет предотвратить деградацию производительности.

Используйте хэшированный индекс. Хэщированный индекс иногда помогает повысить эффективность. Можно создать хэщированное значение на основании других столбцов и сохранить их в отдельном столбце. По этому значению можно будет производить выборку строк. Это подходит только в случае, когда имеет место совпадение значений. (Хэщированные значения бесполезны при поиске внутри какого-то определенного диапазона с применением операторов < или >=.) Хэщированные значения генерируются в СУБД MySQL версии 3.23 и выше с помощью функции MD5 ().

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

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

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

ективная загрузка данных

Большую часть времени пользователь занят оптимизацией запросов SELECT потому, что ЭТО самый популярный запрос языка SQL, и сразу бывает не совсем понятно, как его эффективно применить. (Для сравнения, загрузка данных в таблицу - более простая операция.) Но и для увеличения производительности процесса прямой загрузки данных в базу имеются свои методы. Основные принципы процедуры зафузки данных можно определить следующим образом.

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

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

а Короткие операторы SQL обрабатываются бысфее длинных операторов по двум причинам: синтаксический анализ коротких операторов занимает меньше времени и собственно передача по сети происходит бысфее.

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

а Оператор LOAD DATA всегда эффективнее оператора INSERT потому, что он зафужает данные в массе. Обновление индекса при этом производится значительно реже, а серверу нужно обрабатывать только один оператор.

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

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

INSERT INTO tbl name VALUES(...),{...),...