Один из вариантов исправления этого – сделать экспорт таблицы, добавить нужный collate и импортировать обратно. Например, есть таблица users, правильный вариант команды создания таблицы может быть таким:

CREATE TABLE `users` (
`id` int(11) unsigned NOT NULL auto_increment,
`login` varchar(255) NOT NULL,
...
) ENGINE=MyISAM  DEFAULT CHARSET=utf8 COLLATE utf8_unicode_ci;

Если просто поменять collate через ALTER TABLE, то это не поможет – изменится только свойство collate, а не сами данные.

Удивительно, сколько народу устанавливает mySQL на свои сервера и оставляют его с настройками по умолчанию.

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

• key_buffer_size — крайне важная настройка при использовании MyISAM-таблиц. Установите её равной около 30-40% от доступной оперативной памяти, если используете только MyISAM. Правильный размер зависит от размеров индексов, данных и нагрузки на сервер — помните, что MyISAM использует кэш операционной системы (ОС), чтобы хранить данные, поэтому нужно оставить достаточно места в ОЗУ под данные, и данные могут занимать значительно больше места, чем индексы. Однако обязательно проверьте, чтобы всё место, отводимое директивой key_buffer_size под кэш, постоянно использовалось — нередко можно видеть ситуации, когда под кэш индексов отведено 4 ГБ, хотя общий размер всех .MYI-файлов не превышает 1 ГБ. Делать так совершенно бесполезно, Вы только потратите ресурсы. Если у Вас практически нет MyISAM-таблиц, то key_buffer_size следует выставить около 16-32 МБ — они будут использоваться для хранения в памяти индексов временных таблиц, создаваемых на диске.
• innodb_buffer_pool_size — не менее важная настройка, но уже для InnoDB, обязательно обратите на неё внимание, если собираетесь использовать в основном InnoDB-таблицы, т.к. они значительно более чувствительны к размеру буфера, чем MyISAM-таблицы. MyISAM-таблицы в принципе могут неплохо работать даже с большим количеством данных и при стандартном значении key_buffer_size, однако mySQL может сильно «тормозить» при неверном значении innodb_buffer_pool_size. InnoDB использует свой буфер для хранения и индексов, и данных, поэтому нет необходимости оставлять память под кэш ОС — устанавливайте innodb_buffer_pool_size в 70-80% доступной оперативной памяти (если, конечно, используются только InnoDB-таблицы). Относительно максимального размера данной опции — аналогично key_buffer_size — не стоит увлекаться, нужно найти оптимальный размер, найдите лучшее применение доступной памяти.
• innodb_additional_mem_pool_size — данная опция практически никак не влияет на производительность mySQL, однако рекомендую оставлять для InnoDB около 20 МБ (или чуть больше) под различные внутренние нужды.
• innodb_log_file_size — крайне важная настройка в условиях баз данных с частыми операциями записи в таблицы, в особенности при больших объёмах. Большие размеры увеличивают быстродействие, однако будьте осторожны — увеличится и время восстановления данных. Я обычно выставляю значение около 64-512 МБ в зависимости от размера сервера.
• innodb_log_buffer_size — стандартное значение данной опции вполне подойдёт для большинства систем со средним количеством операций записи и небольшими транзакциями. Если же в Вашей системе бывают всплески активности, или Вы активно работаете с BLOB-данными, то рекомендую немного увеличить значение innodb_log_buffer_size. Однако не переусердствуйте — слишком большое значение будет пустой тратой памяти: буфер сбрасывается каждую секунду, поэтому Вам не понадобится больше места, чем требуется в течение этой секунды. Рекомендуемое значение — около 8-16 МБ, а для небольших баз — и того меньше.
• innodb_flush_log_at_trx_commit — жалуетесь, что InnoDB работает в 100 раз медленнее MyISAM? Вероятно, Вы забыли про настройку innodb_flush_log_at_trx_commit. Значение по умолчанию «1» означает, что каждая UPDATE-транзакция (или аналогичная команда вне транзакции) должна сбрасывать буфер на диск, что достаточно ресурсоёмко. Большинство приложений, в особенности ранее использовавшие таблицы MyISAM, будут хорошо работать со значением «2» (т.е. «не сбрасывать буфер на диск, только в кэш ОС»). Лог, однако, всё равно будет сбрасываться на диск каждые 1-2 секунды, поэтому в случае аварии Вы потеряете максимум 1-2 секунды обновлений. Значение «0» повысит производительность, но Вы рискуете потерять данные даже при аварийной остановке mySQL-сервера, в то время как при установке значение innodb_flush_log_at_trx_commit в «2» Вы потеряете данные только при аварии всей операционной системы.
• table_cache — открытие таблиц может быть весьма ресурсоёмко. К примеру, MyISAM-таблицы помечают заголовки .MYI файлов как «используемые в текущий момент». Обычно не рекомендуется открывать таблицы слишком часто, поэтому лучше, чтобы кэш был достаточных размеров, чтобы держать все Ваши таблицы открытыми. Для этого используется некоторое количество ресурсов ОС и оперативной памяти, однако это обычно не является существенной проблемой для современных серверов. Если у Вас несколько сотен таблиц, то стартовым значением для опции table_cache может быть«1024» (помните, что каждое соединение требует свой собственный дескриптор). Если у Вас ещё больше таблиц или очень много соединений — увеличьте значение параметра. Я видел mySQL сервера со значением table_cache равной 100 000.
• thread_cache — создание/уничтожение потоков также является ресурсоёмкой операцией, которая происходит при каждой установке соединения и каждом разрыве соединения. Я обычно выставляю эту опцию равную 16. Если у Вашего приложения могут быть скачки количество конкурентных соединений и по переменной Threads_Created виден быстрый рост количества потоков, то стоит увеличить значение thread_cache. Цель — не допускать создания новых потоков в условиях нормального функционирования сервера.
• query_cache_size — если Ваше приложение много и часто читает данные, и при этом у Вас нет кэша на уровне приложения, эта опция может очень помочь. Не ставьте здесь слишком большое значение, так как обслуживание большого кэша запросов будет само по себе затратным. Рекомендуемое значение — от 32 до 512 МБ. Не забудьте проверить, насколько хорошо используется кэш запросов — в некоторых условиях (при небольшом количестве хитов в кэше, т.е. когда практически не выбираются одинаковые данные) использование большого кэша может ухудшить производительность.

Как Вы можете видеть, это — глобальные настройки. Эти переменные зависят от «железа» сервера и используемых движков mySQL, в то время как сессионные переменные обычно настраиваются специально под конкретные задачи. Если Вы в основном используете простые запросы, то нет никакой необходимости увеличивать значение sort_buffer_size, даже если у Вас есть лишние 64 ГБ оперативной памяти. Более того, большие значения кэшей могут только ухудшить производительность сервера. Сессионные переменные лучше оставить на потом, для тонкой настройки сервера.

PS: инсталляция mySQL идёт с несколькими предустановленными файлами my.cnf, рассчитанными под разную нагрузку. Если Вам некогда настраивать сервер вручную, то обычно лучше использовать их, чем стандартный конфигурационный файл, выбрав тот, что больше подойдёт под нагрузку Вашего сервера.

mysql> SHOW ENGINES;
+------------+---------+----------------------------------------------------------------+
| Engine     | Support | Comment                                                        |
+------------+---------+----------------------------------------------------------------+
| MyISAM     | YES     | Default engine as of MySQL 3.23 with great performance         |
| MEMORY     | YES     | Hash based, stored in memory, useful for temporary tables      |
| HEAP       | YES     | Alias for MEMORY                                               |
| MERGE      | YES     | Collection of identical MyISAM tables                          |
| MRG_MYISAM | YES     | Alias for MERGE                                                |
| ISAM       | NO      | Obsolete storage engine, now replaced by MyISAM                |
| MRG_ISAM   | NO      | Obsolete storage engine, now replaced by MERGE                 |
| InnoDB     | DEFAULT | Supports transactions, row-level locking, and foreign keys     |
| INNOBASE   | YES     | Alias for INNODB                                               |
| BDB        | YES     | Supports transactions and page-level locking                   |
| BERKELEYDB | YES     | Alias for BDB                                                  |
| NDBCLUSTER | NO      | Clustered, fault-tolerant, memory-based tables                 |
| NDB        | NO      | Alias for NDBCLUSTER                                           |
| EXAMPLE    | NO      | Example storage engine                                         |
| ARCHIVE    | YES     | Archive storage engine                                         |
| CSV        | NO      | CSV storage engine                                             |
| FEDERATED  | YES     | Federated MySQL storage engine                                 |
| BLACKHOLE  | YES     | /dev/null storage engine (anything you write to it disappears) |
+------------+---------+----------------------------------------------------------------+

MyISAM Storage engine

InnoDB Storage engine

Archive Storage engine

Memory Storage engine

Merge Storage engine

BDB Storage engine

NDB Storage engine

FEDERATED Storage engine

BLACKHOLE Storage engine

Falcon Storage engine

Maria Storage engine

MyISAM

Подробней о MyISAM

Движок по умолчанию. Не поддерживает транзакций, средняя надежность хранения данных. Превосходная производительность чтения данных (через SELECT). Блокирует всю таблицу при записи в неё данных, отчего маленькая производительность при частых записях. Распространённый движок.

В версии MySQL 6.* MyISAM планируется заменить на движок Maria.

Maria – это расширенная версия MyISAM, которая поддерживает весь основной функционал MyISAM и в дополнение к этому предлагает: поддержку восстановления данных после сбоев (data auto-recovery, crash safe), полное логирование (включая операции CREATE, DROP, RENAME и TRUNCATE) и новый формат строк PAGE. Более подробно тут.

Примечания:

• Таблицы могут быть повреждены. Ежедневно архивируйте данные или установите еще один MySQL сервер для выполнения репликаций.
• Включите авто-восстановление (auto-repair) в настройках Вашего сервера (my.cnf):
  
  myisam-recover=backup,force

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

• Конкурирующие записи полностью блокируют таблицы. Переключите все, что возможно, на оффлайн обработку записей сериями, что-бы не загружать движок сервера баз данных. (Оффлайн обработка – золотое правило, применимое для всех типов таблиц)
• Таблица MyISAM может быть сжата стандартой утилитой myisampack. Сжатые таблицы MyISAM поддерживают только чтение.Объём не сжатой таблицы:

  +--------------+---------+---------------+------------+
  | table_name   | engine  | total_size_mb | table_rows |
  +--------------+---------+---------------+------------+
  | test_myisam  | MyISAM  |          6.46 |     112050 |
  +--------------+---------+---------------+------------+

  Объём сжатой таблицы:

  C:\Program Files\MySQL\MySQL Server 5.0\data\gim>..\..\bin\myisampack test_myisam.MYI
  Compressing test_myisam.MYD: (112050 records)
  - Calculating statistics
  - Compressing file
  67.76%
  +--------------+---------+---------------+------------+
  | table_name   | engine  | total_size_mb | table_rows |
  +--------------+---------+---------------+------------+
  | test_myisam  | MyISAM  |          2.08 |     112050 |
  +--------------+---------+---------------+------------+

InnoDB

Подробней о InnoDB

Транзакционный тип движка, применяемый при интенсивных операциях записи, благодаря возможности блокировки уровня строк таблицы. Великолепная восстанавливаемость и высокая надежность хранения данных. Поддерживает внешние ключи. Движок InnoDB был приобретен Oracle в 2005 году (под GPL).

Примечания:

• Поддержка ACID транзакций. Встроенная отказоустойчивость данных, равная надежности 99.999%. Блокировка уровня строк (сравните с полной блокировкой всей таблицы в MyISAM) означает обеспечение быстрой записи конкурирующих операций.
• Выполнение “SELECT Count(*) FROM table” без индексов выполняется в InnoDB очень медленно и требует сканирования всей таблицы. (Для MyISAM эта операция ничего не стоит, потому что он хранит внешние записи счетчиков для каждой таблицы).
  
  Если Вам часто необходима операция “SELECT COUNT(*)” на таблицах InnoDB, создайте MySQL триггер на вставку/удаление, который будет увеличивать/уменьшать счетчик, когда данные добавляются или удаляются из таблицы.
• Резервирование (бакапирование)
  
  Простое архивирование всех файлов таблиц для InnoDB невозможно.

  MySQLDump резервирует InnoDB очень медленно. (Если Вы настаиваете на таком резервировании, включите флаг: –opt –compress)

  Быстрое жизнеспособное резервирование, которое так-же может быть использовано как новая “ведомая” (slave) машина, это InnoDB Hot Backup.

• Восстановление
  
  В InnoDB встроена поддержка восстановления, которая работает в 99% случаев автоматически. Никогда не трогайте .frm или .ibd файлы в надежде “помочь” восстановлению базы данных. Если встроенное восстановление не сработало, переключайтесь на “ведомый” сервер и восстанавливайте основной из архивов.
• InnoDB меньше, чем MyISAM, прощает выполнение запросов построенных не на индексах. InnoDB отправит Вас в “школу”, что-бы быть уверенным, что каждый запрос или обновление будет запущено на индексах. Выполните непроиндексированный запрос и Вы поплатитесь за это временем исполнения.
• Никогда не изменяйте my.cnf InnoDB лог файл, когда запущен сервер баз данных. Вы разрушите последовательный лог-номер (log sequence number) оставшись без возможность восстановления.
• Поддерживает внешние ключи.
• Считается, что InnoDB медленнее чем MyISAM, кто так считает просто не умеет его(InnoDB) готовить. Дело в том, что движок InnoDB сильно повязан на оперативной памяти – чем больше оперативной памяти ему дашь, тем быстрее он будет работать, что не наблюдается у MyISAM. Стоит обратить внимание на параметр innodb_buffer_pool_size, по умолчанию он установлен 8 мегабайт, это ничтожно мало, как минимум рекомендуется 1 гигабайт. Подробней о настройках InnoDB можно найти на блоге Зайцева. Народ добивался скорости быстрее чем у MyISAM, выделив, в сумме на InnoDB 16 гигабайт

ARCHIVE

Подробней о ARCHIVE

Используется для хранения больших объемов данных.

Примечание:

• Сильно сжимает информацию.
• Не поддерживает операторы DELETE и UPDATE (только INSERT и SELECT).
• Не поддерживает индексы (в ближайшем будущем обещают добавить поддержку индексов).
• Обычно медленнее чем другие движки.

Тест драйв:

Для теста бралась таблица с чуть более 100 000 записями, Windows XP, laptop Pentium M 2.00 GHz processor, 1GB RAM, running MySQL 5.0.10 beta.

Тест на создание (тест CREATE):

mysql> CREATE TABLE test_myisam ENGINE=myisam AS SELECT * FROM client_transaction_hist;
Query OK, 112050 rows affected (1.06 sec)
Records: 112050  Duplicates: 0  Warnings: 0   mysql> CREATE TABLE test_innodb ENGINE=innodb AS SELECT * FROM client_transaction_hist;
Query OK, 112050 rows affected (3.72 sec)
Records: 112050  Duplicates: 0  Warnings: 0   mysql> CREATE TABLE test_archive ENGINE=archive AS SELECT * FROM client_transaction_hist;
Query OK, 112050 rows affected (1.92 sec)
Records: 112050  Duplicates: 0  Warnings: 0

Подсчитаем объёмы таблиц

mysql> SELECT  table_name table_name,
    ->         engine,
    ->         ROUND(data_length/1024/1024,2) total_size_mb,
    ->         table_rows
    -> FROM   information_schema.tables
    -> WHERE  table_schema = 'gim' and
    ->        table_name like 'test%'
    -> ORDER BY 3;
+--------------+---------+---------------+------------+
| table_name   | engine  | total_size_mb | table_rows |
+--------------+---------+---------------+------------+
| test_archive | ARCHIVE |          1.64 |     112050 |
| test_myisam  | MyISAM  |          6.46 |     112050 |
| test_innodb  | InnoDB  |          9.52 |     112050 |
+--------------+---------+---------------+------------+

Соответственно даже после сжатия MyISAM таблицы Archive будет показывать лучший вариант.

+--------------+---------+---------------+------------+
| table_name   | engine  | total_size_mb | table_rows |
+--------------+---------+---------------+------------+
| test_archive | ARCHIVE |          1.64 |     112050 |
| test_myisam  | MyISAM  |          2.08 |     112050 |
| test_innodb  | InnoDB  |          9.52 |     112050 |
+--------------+---------+---------------+------------+

Не всегда ARCHIVE медленный, чем больше строк тем лучший он может показать результат. На примере теста вставки (тест INSERT) 1 000 000 строк

mysql> CREATE TABLE insert_test (c1 int, c2 varchar(20)) engine=myisam;
Query OK, 0 rows affected (0.00 sec)   mysql> DROP PROCEDURE test_insert;
Query OK, 0 rows affected (0.00 sec)   mysql> delimiter //
mysql> create procedure test_insert()
    -> begin
    -> declare v_ctr tinyint;
    -> set v_ctr = 0;
    -> while v_ctr < 1000000
    -> do
    ->     insert into insert_test values (1,'testing insert');
    ->     set v_ctr = v_ctr + 1;
    -> end while;
    -> end
    -> //
Query OK, 0 rows affected (0.00 sec)   mysql> delimiter ;
mysql> CALL test_insert();
Query OK, 1 row affected (33.06 sec)   mysql> TRUNCATE TABLE insert_test;
Query OK, 0 rows affected (0.01 sec)   mysql> ALTER TABLE insert_test engine=archive;
Query OK, 0 rows affected
Records: 0  Duplicates: 0  Warnings: 0   mysql> CALL test_insert();
Query OK, 1 row affected (21.42 sec)

Archive показал результат, луче быстрого MyISAM’a.

Другой подход заключается что бы загрузить стандартные таблицы MyISAM, а затем выполнить сжатие (тест ALTER TABLE)

mysql> ALTER TABLE myisam_insert ENGINE=archive;
Query OK, 3000000 rows affected, 0 warning (8.84 sec)
Records: 3000000  Duplicates: 0  Warnings: 0

Тест на сканирование (тест SELECT COUNT)

mysql> SELECT COUNT(*) FROM test_myisam WHERE client_id = 50;
+----------+
| count(*) |
+----------+
|       24 |
+----------+
1 row in set (0.25 sec)   mysql> SELECT COUNT(*) FROM test_innodb WHERE client_id = 50;
+----------+
| count(*) |
+----------+
|       24 |
+----------+
1 row in set (0.59 sec)   mysql> SELECT COUNT(*) FROM test_archive WHERE client_id = 50;
+----------+
| count(*) |
+----------+
|       24 |
+----------+
1 row in set (0.41 sec)

Тут Archive оказался медленее MyISAM, но быстрее InnoDB.

Так же не стоит забывать, что Archive поддерживается MySQL Query Cache.

Теперь проверим на 3 000 000 записей:

mysql> SELECT COUNT(*) FROM myisam_insert WHERE c1 = 1;
+----------+
| count(*) |
+----------+
|  3000000 |
+----------+
1 row in set (1.05 sec)   mysql> SELECT COUNT(*) FROM archive_insert WHERE c1 = 1;
+----------+
| count(*) |
+----------+
|  3000000 |
+----------+
1 row in set (2.20 sec)   mysql> FLUSH STATUS;
Query OK, 0 rows affected (0.00 sec)   mysql> SELECT COUNT(*) FROM archive_insert WHERE c1 = 1;
+----------+
| count(*) |
+----------+
|  3000000 |
+----------+
1 row in set (0.00 sec)   mysql> SHOW STATUS LIKE 'qcache_hits';
+-------------------------+----------+
| Variable_name           | Value    |
+-------------------------+----------+
| Qcache_hits             | 1        |
+-------------------------+----------+

MEMORY aka HEAP

Подробней о MEMORY

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

Примечания:

• Этот тип таблиц предлагает супер быстрый возврат данных, который работает только для небольших временных таблиц.
  
  Если загружаете слишком большие объемы данных в Memory таблицы, MySQL начинает свопировать информацию на диск и тем самым Вы теряете все преимущества Memory движка.
• Таблицы не располагают многими возможностями обычных таблиц. Они не могут иметь столбцы типа BLOB или TEXT. Нельзя использовать флаг AUTO_INCREMENT.
• Можно создавать индексы, но нельзя индексировать столбцы, допускающие значения NULL. Индексы используются только в операциях = и <=> .
• Записи таблиц имеют фиксированную длину. Для столбцов типа VARCHAR сразу выделяется максимальное число байтов. Поскольку память — ограниченный ресурс, можно задать предельное количество записей в резидентной таблице.
  
  Для этого предназначена опция max_rows инструкции CREATE TABLE. Серверная переменная max_heap_table_size задает максимальный объем памяти, занимаемой всеми резидентными таблицами.

  С версии MySQL 5.1 будет включена поддержка VARCHAR.

MERGE aka MRG_ISAM

Подробней о MERGE

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

Примечания:

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

Примеры:

CREATE TABLE t1 (a INT AUTO_INCREMENT PRIMARY KEY, message CHAR(20));
CREATE TABLE t2 (a INT AUTO_INCREMENT PRIMARY KEY, message CHAR(20));
INSERT INTO t1 (message) VALUES ("Testing"),("table"),("t1");
INSERT INTO t2 (message) VALUES ("Testing"),("table"),("t2");
CREATE TABLE total (a INT NOT NULL, message CHAR(20), KEY(a))
TYPE=MERGE UNION=(t1,t2) INSERT_METHOD=LAST;

Не создавайте UNIQUE или PRIMARY KEY в таблице total если не уверенны что ключ будет уникальным.

mysql> SELECT * FROM total;
+---+---------+
| a | message |
+---+---------+
| 1 | Testing |
| 2 | table   |
| 3 | t1      |
| 1 | Testing |
| 2 | table   |
| 3 | t2      |
+---+---------+

BDB aka BERKELEYDB

Подробней о BDB

Смесь MyISAM и InnoDB. С функциональной точки зрения таблицы BDB ведут себя аналогично таблицам MyISAM. Нет никаких ограничений на число столбцов или индексов. Во всём основном BDB как InnoDB: поддерживает тразакции, команда SELECT COUNT(*) FROM table_name выполняется медленно и тп. Однако BDB уступает в самовосстановлении данных InnoDB. Не смотря на все его большие возможности, BDB не получило распространение.

! В ближайшем будущем (точнее с MySQL 5.1) поддержка этого движка прекратится. (источник)

Примечания:

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

NDB aka NDBCluster

Подробней о NDB

Кластерный движок – данные автоматически разделяются и реплицируются по различным машинам, именуемым – дата узлы. Применяется для приложений, которые требуют высокой производительности с наивысшей степенью доступности. NDB хорошо работает на системах требующих высокой отдачи на операциях чтения. Для “тяжелых” приложений требующих активной записи в конкурирующей среде рассмотрите вариант с InnoDB.

FEDERATED

Подробней о FEDERATED

Позволяет “монтировать” удалённую таблицу на локальном сервере. По сути, скопировать содержимое.

Примечания:

• Для создания FEDERATED таблицы необходимо существование удалённой таблицы.
• Нельзя использовать ALTER TABLE.
• Не поддерживает тразакции.
• FEDERATED таблице не известно о каких-либо структурных изменениях, которые могут произойти в удалённой таблице. Можете схлопотать ошибки во время выполнения.

Примеры:

Таблица на удалённом сервере.

CREATE TABLE `City` (
  `ID` int(11) NOT NULL auto_increment,
  `Name` char(35) NOT NULL default '',
  `CountryCode` char(3) NOT NULL default '',
  `District` char(20) NOT NULL default '',
  `Population` int(11) NOT NULL default '0',
  PRIMARY KEY  (`ID`)
) ENGINE=MyISAM;

Таблица на локальном сервере

CREATE TABLE `City` (
  `ID` int(11) NOT NULL auto_increment,
  `Name` char(35) NOT NULL default '',
  `CountryCode` char(3) NOT NULL default '',
  `District` char(20) NOT NULL default '',
  `Population` int(11) NOT NULL default '0',
  PRIMARY KEY  (`ID`)
) ENGINE = FEDERATED
connection='mysql://user:pass@remote.com:3306/world/City';

SELECT * FROM City WHERE ID = 1;   +----+-------+-------------+----------+------------+
| ID | Name  | CountryCode | District | Population |
+----+-------+-------------+----------+------------+
|  1 | Kabul | AFG         | Kabol    |    1780000 |
+----+-------+-------------+----------+------------+

BLACKHOLE aka /dev/null engine

Подробней о BLACKHOLE

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

Примечания:

• Поддерживает все виды индексов.
• Не сохраняет данные, однако ведёт двоичный журнал (binary log) действий, если, конечно, он включен.
  
  Это может быть полезно в качестве репликации или фильтра.

  Другие возможные использования BLACKHOLE:

  - Проверка синтаксиса файла дампа.

  - Измерение непроизводительных(?) затрат, сравнивая показатели BLACKHOLE с учетом и без учета двоичного логирования.

  - Может использоваться для нахождения критических параметров эффективности комманд, не связанных с типом движка непосредственно.

Примеры:

mysql> CREATE TABLE test(i INT, c CHAR(10)) ENGINE = BLACKHOLE;
Query OK, 0 rows affected (0.03 sec)   mysql> INSERT INTO test VALUES(1,'record one'),(2,'record two');
Query OK, 2 rows affected (0.00 sec)
Records: 2  Duplicates: 0  Warnings: 0   mysql> SELECT * FROM test;
Empty set (0.00 sec)

Falcon

Подробней о Falcon

Появится в MySQL 5.2. В настоящее время (5.2.0-alpha), движок находится в состоянии alpha. Функциональный и быстрый движок.

• полная поддержка транзакций (full ACID)
• поддержка ссылочной целостности таблиц
• хранение всех типов данных MySQL
• оптимизации для работы с большим количеством оперативной памяти
• полная мультиверсионность, позволяющая уменьшить, а иногда полностью устранить необходимость в блокировках
• сжатие данных
• алгоритмы работы с диском

Впоследствии вполне сможет стать хорошей заменой для InnoDB.

Maria

Подробней о Maria

Новый MySQL движок для хранения данных. Maria представляет собой расширенную версию хранилища MyISAM, с добавлением средств сохранения целостности данных после краха.

Примечания:

• В случае краха производится откат результатов выполнения текущей операции или возврат в состояние до команды LOCK TABLES. Реализация через ведение лога операций;
• Возможность восстановления состояния из любой точки в логе операций, включая поддержку CREATE/DROP/RENAME/TRUNCATE. Может быть использовано для создания инкрементальных бэкапов, через периодическое копирование лог файла.
• Поддержка всех форматов столбцов MyISAM, расширена новым форматом “rows-in-block”, использующим страничный механизм хранения данных, при котором данные в столбцах могут кэшироваться;
• В будущем будет реализовано два режима: транзакционный и без отражения в логе транзакций, для не критичных данных.
• В Maria размер страницы данных равен 8Кб (в MyISAM 1Кб), что позволяет достичь более высокой производительности для индексов по полям фиксированного размера, но медленнее в случае индексирования ключей переменной длинны.
• Недостатки которые планируется устранить: неэффективная работа со столбцами, данные в которых занимают менее 25 байт; Maria 1.0 поддерживает один поток записи или много на чтение (в MyISAM – один на запись _и_ много на чтение (concurrent insert)); нет поддержки INSERT DELAYED.

• Поисковый движок – NDB кластер
• Логирование веб статистики – Обычные файлы для логирования с оффлайновым обработчиком и записью всей статистики в InnoDB таблицы
• Финансовые транзакции – InnoDB
• Сессионные данные – MyISAM или NDB кластер
• Локальные расчеты – HEAP
• Словари – MyISAM

Полезные ссылки:

http://mysqlinfo.ru/anything_VidiTablicISposobIhHraneniya.htm

http://dev.mysql.com/tech-resources/articles/storage-engine.html

http://dev.mysql.com/doc

http://www.mysql.ru/docs/man/

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

Восстановление & Оптимизация

mysqlcheck -Aor

Только ввостановление

mysqlcheck -Ar

Только оптимизация

mysqlcheck -Ao

Описание аргументов:
-A – Проверить на ошибки все Mysql базы данных
-r – Отремонтировать все Mysql базы данных
-o – Оптимизировать все Mysql базы данных ]]> http://iphp.com.ua/archives/408/feed 0 http://iphp.com.ua/archives/384 http://iphp.com.ua/archives/384#comments Sun, 22 Mar 2009 05:36:08 +0000 admin http://iphp.com.ua/?p=384 Какую таблицу из двух выбрать для своей базы данных в случае использования UTF?

utf8_general_ci
Убирает все акценты и приводит к верхнему регистру: ÀÁÅåāă = A, ü = U.
Не очень точно отрабатывает при сортировках. Иногда полезно при поиске. Быстрее utf8_unicode_ci.

Подходит для Русского. При использовании Белорусского и Украинского сортировка будет не верной.

utf8_unicode_ci
Довольно точно при сортировке и поиске. Например, ß (немецкий эсцет) будет при сортировке располагаться рядом с ss, как ему и положено. Медленнее utf8_general_ci.

Замечательно подходит для Русского, Белорусского и Украинского.

Итог
Если проект исключительно русскоязычный и скорость поиска и сравнения критична — можно остановится на utf8_general_ci. Если же есть планы по поддержке большего количества языков — лучше использовать utf8_unicode_ci.

Полные таблички utf8_unicode_ci и utf8_general_ci (там, кстати, и все остальные есть).

Master1 server ip: 10.0.0.1
Master2 server ip: 10.0.0.2
Slave username: slaveuser
Slave pw: slavepw
Your data directory is: /usr/local/mysql/var/

Let us go through the steps you must take on Master1 to enable it to act as master and slave by using following configuration which goes under [mysqld] section:

# let’s make it so auto increment columns behave by having different increments on both servers

auto_increment_increment=2
auto_increment_offset=1
# Replication Master Server
# binary logging is required for replication
log-bin=master1-bin
binlog-ignore-db=mysql
binlog-ignore-db=test
# required unique id between 1 and 2^32 - 1
server-id = 1
#following is the slave settings so this server can connect to master2
master-host = 10.0.0.2
master-user = slaveuser
master-password = slavepw
master-port = 3306

Following is the configuration which goes on master2 under [mysqld] section:

# let's make it so auto increment columns behave by having different increments on both servers
auto_increment_increment=2
auto_increment_offset=2
# Replication Master Server
# binary logging is required for replication
log-bin=master2-bin
binlog-ignore-db=mysql
binlog-ignore-db=test
# required unique id between 1 and 2^32 - 1
server-id = 2
#following is the slave settings so this server can connect to master2
master-host = 10.0.0.1
master-user = slaveuser
master-password = slavepw
master-port = 3306

On master1 server, go to mysql> prompt and add the appropriate user:

mysql> grant replication slave on *.* to slaveuser@'10.0.0.2' identified by 'slavepw';

On master2 server do the same but allow right ip:

mysql> grant replication slave on *.* to slaveuser@'10.0.0.1' identified by 'slavepw';

Restart both of the master servers and check slave status:

mysql> show slave status;

That is all you have to do to set up the replication. Of course there are a lot more configuration options but this should get your replication going and you can tweak from here on.

This script takes information from “SHOW STATUS LIKE…” and “SHOW VARIABLES LIKE…”
to produce sane recomendations for tuning server variables.
It is compatable with all versions of MySQL 3.23 and higher (including 5.1).

Matthew Montgomery has created a script called MySQL performance tuning primer script that generates recomendations for tuning MySQL server variables like:
Slow Query Log
Max Connections
Worker Threads
Key Buffer
Query Cache
Sort Buffer
Joins
Temp Tables
Table (Open & Definition) Cache
Table Locking
Table Scans (read_buffer)
Innodb Status

It’s designed to work on Linux, Solaris, FreeBSD, MacOS and possible on other UNIX based systems using MySQL server version 3.23+ (including 5.1).

First, you need to grab a copy of this script:
wget http://www.day32.com/MySQL/tuning-primer.sh

Before you continue, make sure your MySQL server has at least 48 hours uptime. It’s very important for the script in order to adjust variables corectly.

Running this script is like any other Unix shell script :
sh ./tuning-primer.sh [mode]

Available Modes:
all : perform all checks (default)
prompt : prompt for login credintials and socket and execution mode
mem, memory : run checks for tunable options which effect memory usage
disk, file : run checks for options which effect i/o performance or file handle limits
innodb : run InnoDB checks
misc : run checks for that don’t categorise well Slow Queries, Binary logs, Used Connections and Worker Threads

Read carefully then adjust MySQL server configuration file (usually /etc/my.cnf) and restart MySQL server. It is a good practice to backup your server configuration file before. After few days run again the script and take note of what it says. Tweak again the server if necessary.

Remember, this optimization script only takes care of some server variables and it does not teach you how to use proper indexes and table definitions.

You may also want to check out this good article from MySQL on performance tuning.. Now onto the show..

Benchmarking

As with all improvement activities, it is better to start with a known problem area that is able to be defined, or an activity where improvement will provide maximum benefit (the 80/20 rule works everywhere). Nobody can really grasp an intangible goal like “we want to achieve excellence” [4].

The following are decent guidelines to start with [1]:
» Target. You must have a target.
» Establish a baseline.
» Change only one thing at a time (if possible).
» Record Everything, you will need it at some point.
» Optionally disable query_cache, by setting query_cache_size = 0 for benchmarking.

In addition, the following benchmarking utilities may prove to be useful [5]:
» Super Smack – http://vegan.net/tony/supersmack/

Super Smack is a benchmarking, stress testing, and load generation tool for MySQL (and PostgreSQL). Super Smack was originally written by Sasha Pachev, and then hosted and maintained by Jeremy Zawodny.
» SysBench – http://sysbench.sourceforge.net/

SysBench is a modular, cross-platform and multi-threaded benchmark tool for evaluating OS parameters that are important for a system running a database under intensive load.
» mybench – http://jeremy.zawodny.com/mysql/mybench/

mybench is a simple benchmarking framework for MySQL, written in Perl. It consists of a module (MyBench.pm) and an example script (bench_example) that you should customize to suit your needs.

Profiling concepts
» Be familiar with the Explain command and access types in the explain command.
» Use slow query log and mysqldumpslow command to help you determine where problems really exists.
» Low hanging fruit. Tackle stuff that is getting you the best ROI on your time.
» Use MyTOP by Jeremy Zawodny
» Use tuning-primer.sh – http://www.day32.com/MySQL/

Sources of problem
» Poor indexes
» Inefficient or Bloated schema design.
» Bad coding practices, using joins is typically more efficient than subqueries.
» Server variables
» Tuning parameters help but are specific to scenario OLTP, OLAP, memory, system Architecture, storage engine. Meaning, no one size fits all solution really exists. However, you can tune based on some recommendations from other parameters.
» Tweak one thing, rerun benchmarks..
» Server and network bottlenecks

Index Guidelines
» Poor or missing indexes are the fastest way to kill a system.
» Look for covering index opportunities.
» MySQL gets all info from index records, and uses it to complete the query, without having to go into the data records.
» Ensure good selectivity on index fields.
» Make sure you look at selectivity, or cardinality (unique values / total values in table). [ cardinality of 1 is the best case ].
» Multi-column indexes, pay attention to order of fields.
» As database grows ensure distribution is good. Know how your data changes over time. Re-analyze your data and distribution of indexes over time.
» Remove redundant indexes for faster write performance.

System tuning
» Be aware of global vs threaded parameters, key buffers size, global. Sort buffer size, per thread.
» Make small changes (preferably single), retest.
» System parameter tuning is often a quick, temporary solution to a larger issue.
» Query_cache, off by default.
» read intensive applications, turn query_cache on.
» Key_buffer_size != innodb_buffer_pool_size
» innodb_buffer_pool_size about 50-90% of total memory suggested typically.
» Ensure you have analyzed and optimized your tables.

You may also be surprised at just what an effect optimizing a MyISAM table that has dynamic rows will do.. use the ‘optimize table’ SQL command

Parameters

table_cache

Opening tables can be expensive. For example MyISAM tables mark MYI header to mark table as currently in use. You do not want this to happen so frequently and it is typically best to size your cache so it is large enough to keep most of your tables open. Use the tuning-primer.sh (http://www.day32.com/MySQL/) script to evaluate the current value.

query_cache_size

If your application is read intensive and you do not have application level caches this can be great help. Use the tuning-primer script to evaluate the size after you enable it. A good starting point may be 8M.

The query_cache_size will be aligned to the nearest 1024 byte block. The value reported may therefore be different from the value that you set.

If the query cache size is greater than 0, then query_cache_type variable influences how it works. This variable can be set to the following values:

query_cache_type

* A value of 0 or OFF prevents caching or retrieval of cached results.
* A value of 1 or ON allows caching except of those statements that begin with SELECT SQL_NO_CACHE.
* A value of 2 or DEMAND causes caching of only those statements that begin with SELECT SQL_CACHE.

thread_cache

mysql> SHOW STATUS LIKE ‘Thread%’;
mysq> show status like ‘Connections’;Threads_created details the number of threads that have been created since the MySQL server started, and Connections is the total number of client connections to the MySQL server since startup. To work out the thread cache hit ratio, we use this calculation:

100 – ((Threads_created / Connections) * 100)
100 – ((10 / 78298) * 100) = ~99.987 Thread cache hit ratio

The ideal situation is to get Threads_created as close as possible to thread_cache_size – no new connections having to wait for new thread allocation – staying as close to around a 99% hit ratio as you can.

mysql> show status like ‘Select_full_join’;

The number of joins that do not use indexes. If this value is not 0, you should carefully check the indexes of your tables.
ratio of disk tmp tables vrs in memory tmp tables (tmp_table_size)

Handler_read_rnd

mysql> show status like ‘Handler_read_rnd%’;

The number of requests to read a row based on a fixed position. This value is high if you are doing a lot of queries that require sorting of the result. You probably have a lot of queries that require MySQL to scan entire tables or you have joins that don’t use keys properly.

Handler_read_rnd_next

The number of requests to read the next row in the data file. This value is high if you are doing a lot of table scans. Generally this suggests that your tables are not properly indexed or that your queries are not written to take advantage of the indexes you have.

key_buffer_size

Very important if you use MyISAM tables. key_buffer_size is important for MyISAM temporary tables performance to avoid OS writes, see this page for more detail. Again, evaluate the value using the tuning-primer.sh script.

innodb_buffer_pool_size

This is very important variable to tune if you’re using Innodb tables. Innodb tables are much more sensitive to buffer size compared to MyISAM.

innodb_additional_mem_pool_size

This one does not really affect performance too much, at least on OS with decent memory allocators. Still you might want to have it 20MB (sometimes larger) so you can see how much memory Innodb allocates for misc needs.

innodb_log_file_size

Very important for write intensive workloads especially for large data sets. Larger sizes offer better performance but increase recovery times so be careful. I normally use values 64M-512M depending on server size.

innodb_log_buffer_size

Default for this one is kind of OK for many workloads with medium write load and shorter transactions. If you have update activity spikes however or work with blobs a lot you might want to increase it. Do not set it too high however as it would be waste of memory – it is flushed every 1 sec anyway so you do not need space for more than 1 sec worth of updates. 8MB-16MB are typically enough. Smaller installations should use smaller values.

innodb_flush_logs_at_trx_commit

Default value of 1 will mean each update transaction commit (or each statement outside of transaction) will need to flush log to the disk which is rather expensive, especially if you do not have Battery backed up cache. Many applications, especially those moved from MyISAM tables are OK with value 2 which means do not flush log to the disk but only flush it to OS cache. The log is still flushed to the disk each second so you normally would not loose more than 1-2 sec worth of updates. Value 0 is a bit faster but is a bit less secure as you can lose transactions even in case MySQL Server crashes. Value 2 only cause data loss with full OS crash.

OPTIMIZE TABLE should be used if you have deleted a large part of a table or if you have made many changes to a table with variable-length rows (tables that have VARCHAR, VARBINARY, BLOB, or TEXT columns).

References

1. Performance Tuning Best Practices for MySQL, Google TechTalks April 28, 2006. http://video.google.com/videoplay?docid=2524524540025172110

2. [HowTo] Optimising MYSQL, 01-20-2005, 03:59 AM. http://interworx.info/forums/showthread.php?p=2346

3. Kaiser’s 7-Step Benchmarking Process. http://www.kaiserassociates.com/about/bench_7step.html

4. How do you identify a suitable activity to benchmark? http://www.quality.co.uk/benchadv.htm

5. MySQL Benchmarking. http://mysqldatabaseadministration.blogspot.com/2006/08/mysql-benchmarking-1.html

Подробности тут.

RESET MASTER

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

Можно поставить в еженедельный cron.