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

Итак, в 4 версии у ряда переменных появилось окончание _size . Это касается переменной thread_cache_size и переменных из раздела Буферы . А переменная read_buffer_size до версии 4 называлась record_buffer . Также переменная skip_external_locking из раздела Базовые настройки до версии 4 называлась skip_locking .
Переменные делятся на две основных категории: переменные со значениями и переменные-флаги. Переменные со значениями записываются в конфигурационном файле в виде variable = value , а переменные-флаги просто указываются. Также вы наверное заметили, что в некоторых случаях в названиях переменных используется " - ", а в некоторых " _ ". Переменные с дефисом являются стартовыми опциями сервера и их нельзя изменить при работе сервера (при помощи SET); переменные с подчеркиванием являются опциями работы сервера и их возможно изменять на лету. Если речь идет о «переменной состояния» или рекомендуется наблюдать за значением переменной, название которой записано в виде Variable_Name , то следует выполнять запрос SHOW STATUS LIKE "Variable_Name" для получения значения этой переменной, либо заглянуть на вкладку состояние в phpMyAdmin, где дополнительно будут комментарии по значению этой переменной.
А теперь займемся описанием переменных и их возможными значениями.

Базовые настройки

  • low-priority-updates - эта опция снижает приоритет операций INSERT/UPDATE по сравнению с SELECT. Актуально, если данные важно быстрее прочитать, чем быстрее записать.
  • skip-external-locking - опция установлена по умолчанию, начиная с версии 4. Указывает MySQL-серверу не использовать внешние блокировки при работе с базой. Внешние блокировки необходимы в ситуациях, когда несколько серверов работают с одними и теми же файлами данных, т.е. имеют одинаковую datadir , что на практике не используется.
  • skip-name-resolve - не определять доменные имена для IP-адресов подключающихся клиентов. При этом пользовательские разрешения нужно настраивать не на хосты, а на IP-адреса (за исключением localhost). Если вы соединяетесь с сервером только с локальной машины, то особого значения не имеет. Для внешних соединений ускорит установку соединения.
  • skip-networking - не использовать сеть, т.е. вообще не обрабатывать TCP/IP соединения. Общение с сервером при этом будет происходить исключительно через сокет. Рекомендуется, если у вас нет ПО, которое использует только TCP/IP для связи с сервером.

Ограничения

  • bind-address - интерфейс, который будет слушать сервер. В целях безопасности рекомендуется установить здесь 127.0.0.1, если вы не используете внешние соединения с сервером.
  • max_allowed_packet - максимальный размер данных, которые могут быть переданы за один запрос. Следует увеличить, если столкнетесь с ошибкой «Packet too large».
  • max_connections - максимальное количество параллельных соединений к серверу. Увеличьте его, если сталкиваетесь с проблемой «Too many connections».
  • max_join_size - запрещает SELECT операторы, которые предположительно будут анализировать более указанного числа строк или больше указанного числа поисков по диску. Используется для защиты от кривых запросов, которые пытаются считать миллионы строк. Значение по умолчанию более 4 миллиардов, поэтому вы скорее всего захотите его значительно уменьшить.
  • max_sort_length - указывает, сколько байт из начала полей типа BLOB или TEXT использовать при сортировке. Значение по умолчанию 1024, если вы опасаетесь некорректно спроектированных таблиц или запросов, то следует его уменьшить.

Настройки потоков

  • thread_cache_size - указывает число кэшируемых потоков. После обработки запроса сервер не будет завершать поток, а разместит его в кэше, если число потоков, находящих в кэше меньше, чем указанное значение. Значение по умолчанию 0, увеличьте его до 8 или сразу до 16. Если наблюдается рост значения переменной состояния Threads_Created , то следует еще увеличить thread_cache_size .
  • thread_concurrency - актуально только для Solaris/SunOS вопреки тому, что пишут в сети. «Подсказывает» системе сколько потоков запускать одновременно, выполняя вызов функции thr_setconcurrency . Рекомендованное значение - двойное или утроенное число ядер процессора.

Кэширование запросов

  • query_cache_limit - максимальный размер кэшируемого запроса.
  • query_cache_min_res_unit - минимальный размер хранимого в кэше блока.
  • query_cache_size - размер кэша. 0 отключает использование кэша. Для выбора оптимального значения необходимо наблюдать за переменной состояния Qcache_lowmem_prunes и добиться, чтобы ее значение увеличивалось незначительно. Также нужно помнить, что излишне большой кэш будет создавать ненужную нагрузку.
  • query_cache_type - (OFF, DEMAND, ON). OFF отключает кэширование, DEMAND – кэширование будет производиться только при наличии директивы SQL_CACHE в запросе, ON включает кэширование.
  • query_cache_wlock_invalidate - определяет будут ли данные браться из кеша, если таблица, к которым они относятся, заблокирована на чтение.
Кэш запросов можно представить себе как хэш-массив, ключами которого являются запросы, а значениями - результаты запросов. Кроме результатов, MySQL хранит в кэше список таблиц, выборка из которых закэширована. Если в любой из таблиц, выборка из которой есть в кэше, проиcходят изменения, то MySQL удаляет из кэша такие выборки. Также MySQL не кеширует запросы, результаты которых могут измениться.
При запуске MySQL выделяет блок памяти размером в query_cache_size . При выполнении запроса, как только получены первые строки результата сервер начинает кэшировать их: он выделяет в кэше блок памяти, равный query_cache_min_res_unit , записывает в него результат выборки. Если не вся выборка поместилась в блок, то сервер выделяет следующий блок и так далее. В момент начала записи MySQL не знает о размере получившейся выборки, поэтому если записанный в кэш размер выборки больше, чем query_cache_limit , то запись прекращается и занятое место освобождается, следовательно, если вы знаете наперед, что результат выборки будет большим, стоит выполнять его с директивой SQL_NO_CACHE .

Тайминги

  • interactive_timeout - время в секундах, в течение которого сервер ожидает активности со стороны интерактивного соединения (использующего флаг CLIENT_INTERACTIVE ), прежде чем закрыть его.
  • log_slow_queries - указывает серверу логировать долгие («медленные») запросы (выполняющиеся дольше long_query_time). В качестве значения передается полное имя файла (например /var/log/slow_queries).
  • long_query_time - если запрос выполняется дольше указанного времени (в секундах), то он будет считаться «медленным».
  • net_read_timeout
  • net_write_timeout - время в секундах, в течение которого сервер будет ожидать получения данных, прежде чем соединение будет прервано. Если сервер не обслуживает клиентов с очень медленными или нестабильными каналами, то 15 секунд здесь будет достаточно.
  • wait_timeout - время в секундах, в течение которого сервер ожидает активности соединения, прежде чем прервет его. В общем случае 30 секунд будет достаточно.

Буферы

У всех буферов есть общая черта - если из-за установки большого размера буфера данные будут уходить в файл подкачки, то от буфера будет больше вреда, чем пользы. Поэтому всегда ориентируйтесь на доступный вам объем физической ОЗУ.
  • key_buffer_size - размер буфера, выделяемого под индексы и доступного всем потокам. Весьма важная настройка, влияющая на производительность. Значение по умолчанию 8 МБ, его однозначно стоит увеличить. Рекомендуется 15-30% от общего объема ОЗУ, однако нет смысла устанавливать больше, чем общий размер всех.MYI файлов. Наблюдайте за переменными состояния Key_reads и Key_read_requests , отношение Key_reads/Key_read_requests должно быть как можно меньше (< 0,01). Если это отношение велико, то размер буфера стоит увеличить.
  • max_heap_table_size - максимальный допустимый размер таблицы, хранящейся в памяти (типа MEMORY). Значение по умолчанию 16 МБ, если вы не используете MEMORY таблиц, то установите это значение равным tmp_table_size .
  • myisam_sort_buffer_size - размер буфера, выделяемого MyISAM для сортировки индексов при REPAIR TABLE или для создания индексов при CREATE INDEX, ALTER TABLE . Значение по умолчанию 8 МБ, его стоит увеличить вплоть до 30-40% ОЗУ. Выигрыш в производительности соответственно будет только при выполнении вышеупомянутых запросов.
  • net_buffer_length - объем памяти, выделяемый для буфера соединения и для буфера результатов на каждый поток. Буфер соединения будет указанного размера и буфер результатов будет такого же размера, т.е. на каждый поток будет выделен двойной размер net_buffer_length . Указанное значение является начальным и при необходимости буферы будут увеличиваться вплоть до max_allowed_packet . Размер по умолчанию 16 КБ. В случае ограниченной памяти или использования только небольших запросов значение можно уменьшить. В случае же постоянного использования больших запросов и достаточного объема памяти, значение стоит увеличить до предполагаемого среднего размера запроса.
  • read_buffer_size - каждый поток при последовательном сканировании таблиц выделяет указанный объем памяти для каждой таблицы. Как показывают тесты , это значение не следует особо увеличивать. Размер по умолчанию 128 КБ, попробуйте увеличить его до 256 КБ, а затем до 512 КБ и понаблюдайте за скоростью выполнения запросов типа SELECT COUNT(*) FROM table WHERE expr LIKE "a%"; на больших таблицах.
  • read_rnd_buffer_size - актуально для запросов с "ORDER BY ", т.е. для запросов, результат которых должен быть отсортирован и которые обращаются к таблице, имеющей индексы. Значение по умолчанию 256 КБ, увеличьте его до 1 МБ или выше, если позволяет память. Учтите, что указанное значение памяти также выделяется на каждый поток.
  • sort_buffer_size - каждый поток, производящий операции сортировки (ORDER BY ) или группировки (GROUP BY ), выделяет буфер указанного размера. Значение по умолчанию 2 МБ, если вы используете указанные типы запросов и если позволяет память, то значение стоит увеличить. Большое значение переменной состояния Sort_merge_passes указывает на необходимость увеличения sort_buffer_size . Также стоит проверить скорость выполнения запросов вида SELECT * FROM table ORDER BY name DESC на больших таблицах, возможно увеличение буфера лишь замедлит работу (в некоторых тестах это так).
  • table_cache (table_open_cache с версии 5.1.3) - количество кэшированных открытых таблиц для всех потоков. Открытие файла таблицы может быть достаточно ресурсоемкой операцией, поэтому лучше держать открытые таблицы в кэше. Следует учесть, что каждая запись в этом кэше использует системный дескриптор, поэтому возможно придется увеличивать ограничения на количество дескрипторов (ulimit ). Значение по умолчанию 64, его лучше всего увеличить до общего количества таблиц, если их количество в допустимых рамках. Переменная состояния Opened_tables позволяет отслеживать число таблиц, открытых в обход кэша, желательно, чтобы ее значение было как можно ниже.
  • tmp_table_size - максимальный размер памяти, выделяемой для временных таблиц, создаваемых MySQL для своих внутренних нужд. Это значение также ограничивается переменной max_heap_table_size , поэтому в итоге будет выбрано минимальное значение из max_heap_table_size и tmp_table_size , а остальные временные таблицы будут создаваться на диске. Значение по умолчанию зависит от системы, попробуйте установить его равным 32 МБ и понаблюдать за переменной состояния Created_tmp_disk_tables , ее значение должно быть как можно меньше.
Значения в конфигурационном файле задаются в байтах, соответственно килобайты и мегабайты нужно переводить в байты.

InnoDB

  • innodb_additional_mem_pool_size - размер памяти, выделяемый InnoDB для хранения различных внутренних структур. Если InnoDB будет недостаточно этой памяти, то будет запрошена память у ОС и записано предупреждение в лог ошибок MySQL.
  • innodb_buffer_pool_size - размер памяти, выделяемый InnoDB для хранения и индексов и данных. Значение - чем больше, тем лучше. Можно увеличивать вплоть до общего размера всех InnoDB таблиц или до 80% ОЗУ, в зависимости от того, что меньше.
  • innodb_flush_log_at_trx_commit - имеет три допустимых значения: 0, 1, 2. При значении равном 0 , лог сбрасывается на диск один раз в секунду, вне зависимости от происходящих транзакций. При значении равном 1 , лог сбрасывается на диск при каждой транзакции. При значении равном 2 , лог пишется при каждой транзакции, но не сбрасывается на диск никогда, оставляя это на совести ОС. По умолчанию используется 1, что является самой надежной настройкой, но не самой быстрой. В общем случае вы можете смело использовать 2, данные могут быть утеряны лишь в случае краха ОС и лишь за несколько секунд (зависит от настроек ОС). 0 - самый быстрый режим, но данные могут быть утеряны как при крахе ОС, так и при крахе самого сервера MySQL (впрочем данные лишь за 1-2 секунды).
  • innodb_log_buffer_size - размер буфера лога. Значение по умолчанию 1 МБ, увеличивать его стоит, если вы знаете, что будет большое количество транзакций InnoDB или если значение переменной состояния Innodb_log_waits растет. Вам вряд ли придется увеличивать его выше 8 МБ.
  • innodb_log_file_size - максимальный размер одного лог-файла. При достижении этого размера InnoDB будет создавать новый файл. Значение по умолчанию 5 МБ, увеличение размера улучшит производительность, но увеличит время восстановления данных. Установите это значение в диапазоне 32 МБ - 512 МБ в зависимости от размера сервера (оценив его субъективно).
Также для мониторинга работы сервера удобно использовать

Сегодня мы поговорим с Вами о настройке mysql под linux (unix, freebsd) на VPS/VDS сервере. Я не буду касаться аспектов установки mysql на сервер, благо, в интернете достаточно информации.

Где же хранятся настройки mysql?

На Вашем сервере настройки mysql могут находиться или в /etc/my.cnf , или в /etc/mysql/my.cnf , в крайнем случае используйте команду locate , find или им подобные с заданным именем файла

Как изменить настройки mysql?

Итак, файл найден, открыть его можно непосредственно через mc (midnight commander) + F4 или же используя VI(vim): vi my.cnf .

В случае с mc перед Вами будет старый добрый «Norton Commander», если же Вы не знаете, как пользоваться vi , Вам поможет man vi

Когда требуется настройка mysql? Анализ нагрузки mysql

Подсоединитесь с правами администратора базы данных к консоли mysql или же выполните запрос любым удобным для Вас способом, например через phpmyadmin , запрос:

Show processlist;

Все запросы к mysql для проверки значения (мониторинга) тех или иных параметров необходимо выполнять из под пользователя с правами администратора Вашего mysql сервера.

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

А также большое значение в колонке Time во времени выполнения этих запросов указывает на возникновение «медленных» запросов. Также показателем к оптимизации mysql может быть вывод команды top , выполненный через linux консоль.

Вводим в консоли Top , после чего на английской раскладке нажимаем «О», зажимаем «shift» и нажимаем «K» до тех пор, пока %CPU не окажется вначале списка. Зажимаем «shift» и «N» и двигаем в начало списка %MEM . После чего нажимаем «Enter».

Если во главе списка у Вас оказывается «mysql» и показатели в столбце %CPU и %MEM довольно существенны (под 100% загрузка на процессор и почти полностью используется память), Вам точно необходима оптимизация mysql.

Тонкая настройка mysql. Кэширование средствами mysql

Перейдем к тюнингу mysql. Откройте файл my.cnf. Найдите раздел mysqld, все последующие переменные мы будем размещать именно в этом разделе, после строки:

Настраиваем кэш MYSQL

Внутренний кэш запросов mysql:

Query_cache_limit – «ограничиться» максимальным размером данных, которые можно поместить в кэш. Скажу Вам по опыту, в очень редких ситуациях «mysql» запросы будут возвращать данные размером больше 10 MB. Обычно и размера в 2-6 MB хватит с головой.

Например, укажите в my.cnf:

Query_cache_limit = 6MB

Query_cache_size – здесь Вы можете указать, сколько памяти выделить для внутреннего кэша запросов «mysql». В кэш будет добавляться результат запроса целиком («таблица», полученная в результате запроса).

Например, укажите в my.cnf:

Query_cache_size = 64M

Выбор значения query_cache_size

Совет первый: не указывайте слишком большое значение query_cache_size . Обычно указывается значение, равное одной десятой, одной пятой от размера доступной физической оперативной памяти.

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

Как оптимально подобрать значения для query_cache_size, query_cache_limit?

После настройки my.cnf и перезапуска mysql (обычно: /etc/init.d/mysql restart, /etc/rc.d/mysql restart ).

Совет: впрочем, перезапускать mysql после изменения my.cnf нет надобности. Достаточно войти в консоль управления mysql с правами администратора или корневого пользователя root и выполнить запрос на изменение тех или иных переменных.

Set @@global.[название] =[новое значение my.cnf];

Например, для query_cache_size:

Set @@global.query_cache_size=64*1024*1024;

Какие mysql запросы не кэшируются (qcache_not_cached)?

  • insert, update запросы, по существу они приводят к очистки кэша таблицы, для которой выполняются;
  • запросы с применением пользовательских функций и процедур;
  • запросы, использующие временные таблицы;
  • запросы с включением локальных переменных;
  • запросы, использующие SELECT … FOR UPDATE, SELECT … INTO OUTFILE, SELECT … IN SHARE MODE, SELECT * FROM … WHERE autoincrement_col IS NULL, SELECT … INTO DUMPFILE;
  • запросы без обращения к таблицам;
  • запросы с включением некоторых недетерминированных функций: SLEEP(), NOW(),CURTIME(), LAST_INSERT_ID(), RAND();
  • в случае, если пользователь имеет права только на часть таблицы: некоторые ее колонки и т.п.
  • запросы с генерацией предупреждений (warnings).

Через сутки – другие зайдите в консоль управления mysql или выполните запрос любым, удобным для вас способом:

SHOW GLOBAL STATUS LIKE "Qcache%"

Здесь нас интересуют следующие переменные:

  • qcache_not_cached – количество запросов, не подлежащих кэшированию;
  • qcache_inserts – показывает количество результатов mysql запросов, добавляемых в кэш;
  • qcache_hits – показывает количество результатов mysql запросов, извлеченных из кэша, без реального обращения к базе данных;
  • qcache_free_memory – показывает свободную «доступную» память для кэширования;
  • qcache_lowmem_prunes – счетчик, который показывает, сколько раз mysql пришлось принудительно освободить память для добавления новых запросов в кэш mysql.

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

Также «эффективность» работы кэширования можно рассчитать по формуле:

Qcache_hits / (Qcache_inserts + Qcache_not_cached)

Как узнать, что query_cache_size был выбран верно?

На это обычно указывает qcache_free_memory , отличный от нуля. При этом желательно, чтобы параметр qcache_lowmem_prunes стремился к 0. Если же qcache_lowmem_prunes очень велик, рекомендую увеличить query_cache_size .

Настраиваем многопоточность в mysql

Thread_concurrency – количество одновременных процессов, «обрабатывающих» конкурентные запросы к mysql. По документации советуют установить это значение, равное процессорам (ядрам) системы, умноженное на два.

Но и советуют обращать внимание на количество винчестеров, которое использует система, чтобы избежать излишней нагрузки на файловую систему. Тоесть, если Ваш сервер оснащен четырьмя Intel Xeon по 2.8 ГГЦ с hyper Threading, тогда Вам следует установить значение в my.cnf:

Thread_concurrency = 8

Как понять, что значение thread_concurrency установлено верно?

Во время большой нагрузки на сервер после изменения параметра thread_concurrency (наплыва посетителей или при помощи эмуляции нагрузки (например, при помощи Apache Bench с другого сервера )) понаблюдайте за количеством свободной оперативной памяти при помощи той же команды top . Кроме этого обратите внимание на параметр в строке Cpu(s): %wa .

Если значение этого параметра после изменения thread_concurrency выросло, и дошло до 60-90% , советую Вам снизить количество thread_concurrency . Обычно высокое значение %wa свидетельствует о возрастающей нагрузке на файловую подсистему (винчестер).

thread_cache_size – число потоков, которые сервер будет держать в кэше открытыми для обслуживания новых подсоединений. Можно установить равным значению max_connections + 1 (максимально возможному количеству соединений с б.д. +1). Но, чтобы достигнуть максимальной производительности, потребуется мониторинг переменной max_used_connections во время длительного промежутка времени (см. далее).

Т акже советую Вам просмотреть логии Mysql: обычно /var/log/mysql.log на предмет too many connections , когда mysql сервер отвергает подсоединение к базе данных из за того, что было достигнуто максимальное количество разрешенных подсоединений.

Например, при помощи команды grep, выполненной из ssh консоли linux:

Grep "Too many connections" /var/log/mysql.log | more

Совет: путь к логу mysql Вы сможете найти в файле my.cnf.

Если Вы нашли несколько строк с подобной ошибкой, тогда советую Вам увеличить значение max_connections , thread_cache_size , back_log , thread_concurrency :

Например для max_connections, thread_cache_size укажите в my.cnf:

Max_connections = 500 thread_cache_size = 501

Как узнать текущее значение параметра MYSQL, если оно не указано в my.cnf?

Для этого в консоли mysql с правами администратора mysql можно выполнить запрос:

SHOW VARIABLES LIKE "[имя переменных или wild card]";

Например, текущее значение max_connections можно узнать так

SHOW VARIABLES LIKE "max_connections";

Если Вы хотите вывести все переменные, содержащие в своем названии max, можно сформировать такой запрос в консоли mysql:

SHOW VARIABLES LIKE "%max%";

Чтобы получить значения и имена всех без исключения параметров mysql, можно выполнить такой запрос в консоли mysql с правами администратора mysql:

SHOW VARIABLES;

Как подобрать оптимальное значение thread_cache_size?

Выполните из консоли mysql с правами рута или администратора баз данных запрос:

SHOW STATUS LIKE "Max_used_connections";

И постоянно отслеживайте переменную max_used_connections через определенные промежутки времени, ее значение. Если значение max_used_connections = 72 , то устанавливаем значение thread_cache_size = 100 и выше (немногим больше max_used_connections ).

Настраиваем «очередь» конкурентных запросов back_log на подсоединение к mysql серверу.

back_log – сколько запросов на подсоединение к mysql серверу может быть помещено в очередь и в последствии обслужено, если сервер в данный момент занят обработкой запроса на подключение к mysql. По умолчанию пять запросов на подключение будет поставлено в очередь на ожидание. Остальные будут игнорироваться. Если mysql работает под сильной нагрузкой, рекомендую увеличить значение этого параметра.

Количество одновременно открытых таблиц в mysql.

table_cache (с версии Mysql с 5.1.3 – table_open_cache ) - количество открытых таблиц для всех потоков. Дело в том, что открытие таблиц – очень ресурсоемкий процесс, поэтому есть смысл «держать» определенное количество таблиц открытыми в кэше. Если у Вас на сервере используется большое количество таблиц одновременно, можно начать со значения в 1000:

Укажите в my.cnf:

SHOW STATUS LIKE "Opened_tables";

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

Таблицы какого размера хранить в памяти?

max_heap_table_size - максимальный допустимый размер временной таблицы (типа MEMORY (HEAP)), хранящейся в памяти. При превышении этого раз мера таблица будет «создана» на жестком диске.

Например, укажите в my.cnf:

Max_heap_table_size = 64MB

tmp_table_size - максимальный размер памяти для временных таблиц, создаваемых MySQL, которые «хранятся» в оперативной памяти. Если размер временной таблицы превышает указанный, тогда таблица будет «создана» на диске.

Попробуйте установить значение в my.cnf равным 32 – 128 МБ:

Tmp_table_size = 64MB

Понаблюдайте также за состоянием created_tmp_disk_tables , ее значение должно стремиться к 0.

Для этого нужно выполнить запрос в консоли mysql:

SHOW STATUS LIKE "Created_tmp_disk_tables";

Если значение created_tmp_disk_tables гораздо больше нуля, попробуйте увеличить параметр tmp_table_size


Прямая ссылка: mysql-5.5.23-win32.msi
Скачайте самораспаковывающийся архив "Windows (x86, 32-bit), MSI Installer" и запустите его.

Установка MySQL в картинках

Далее будут показаны те диалоговые окна, в которых необходимо делать какой-либо выбор.

Нажмите в данном окне выборочную установку компонентов "Custom".

Теперь приступим к настройке MySQL сервера.

Выбираем детализированную настройку - "Detailed Configuration".

Отмечаем пункт "Developer Machine". Мы ведь разработчики – правда? :)

Выбрав пункт "Multifunctional Database", вы сможете работать как с таблицами типа InnoDB (с возможностью использования транзакций), так и с высокоскоростной MyISAM (как правило для веб-разработок используется именно этот тип таблиц).

Выбор диска и директории для хранения таблиц типа InnoDB.

В данном диалоговом окне выбирается максимально возможное количество подключений к серверу MySQL. При выборе "Decision Support (DSS)/OLAP", максимальное количество подключений будет ограничено двадцатью, чего более чем достаточно при установке сервера на домашнем компьютере и отсутствии большого количества одновременных подключений.

Отметив "Enable TCP/IP Networking" мы включаем поддержку TCP/IP соединений и выбираем порт, через который они будут осуществляться. Стандартным для сервера MySQL является порт 3306. Отметив "Enable Strict Mode", мы задаем режим строгого соответствия стандарту SQL (данную опцию рекомендуется оставлять включенной).

Обратите внимание на выставление настроек данного окна. Отметив "Manual Selected Default Character Set / Collation" и выбрав из ниспадающего меню "cp1251" определяем, что изначально для таблиц будет использоваться кодировка Cyrillic Windows (cp1251), что означает корректную работу с русским языком в данной кодировке.

Если отметить "Install As Windows Service", сервер будет запускаться в виде сервиса, что является рекомендуемым способом запуска. Ниже, в ниспадающем списке, задается имя сервиса. Далее, уберите галочку рядом с "Launch the MySQL Server automatically" - мы будем запускать сервер вручную. Также поставьте галочку рядом с "Include Bin Directory in Windows PATH" - это позволит установить видимость директории "bin", для командной строки.

Установите пароль пользователя "root". Советую сделать это. Поставьте хотя бы какой-нибудь простенький пароль, только не оставляйте поле пустым, это убережёт вас от возможных неприятностей в дальнейшем.

В данном окне обратите внимание на строку "Write configuration file", которая указывает на месторасположение - "my.ini", далее, его необходимо будет немного отредактировать.


Откройте для редактирования файл "my.ini".
  1. В раздел , после строки:
    port=3306
    Добавьте строку определяющую каталог содержащий файлы описания кодировок:
    character-sets-dir="C:/Program Files/MySQL/MySQL Server 5.5/share/charsets"
  2. В раздел , после строки:
    port=3306
    Добавьте следующие две строки, первая из которых вам уже известна, вторая – устанавливает кодировку в которой данные передаются MySQL:
    character-sets-dir="C:/Program Files/MySQL/MySQL Server 5.5/share/charsets"
    init-connect="SET NAMES cp1251"
  3. Далее, найдите строку:
    default-storage-engine=INNODB
    Замените изначально устанавливаемый тип таблиц на MYISAM:
    default-storage-engine=MYISAM
Сохраните изменения и закройте файл "my.ini".
Установка и настройка сервера MySQL – завершена.

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

В Unix считывание принятых по умолчанию параметров MySQL производится из следующих файлов:

DATADIR является каталогом данных MySQL (обычно /usr/local/mysql/data для бинарной установки или /usr/local/var для установки из исходных текстов). Обратите внимание, что это тот каталог, который был задан во время настройки, а не указанный при помощи --datadir при запуске mysqld ! (--datadir не оказывает влияния на просмотр файлов параметров сервером, так как их просмотр происходит до обработки аргументов командной строки).

В Windows считывание принятых по умолчанию параметров MySQL производится из следующих файлов:

Обратите внимание на то, что в Windows все пути необходимо указывать при помощи / вместо \. Если необходимо использовать \, то его нужно указать дважды, так как \ является знаком перехода в MySQL.

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

Приводим список программ, поддерживающих файлы параметров: mysql , mysqladmin , mysqld , mysqld_safe , mysql.server , mysqldump , mysqlimport , mysqlshow , mysqlcheck , myisamchk и myisampack .

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

Файлы параметров могут содержать строки следующего вида:

    Строки комментариев начинаются с символа " # " или " ; ". Пустые строки игнорируются.

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

    Эквивалент --option в командной строке.

    Эквивалент --option=value в командной строке.

    set-variable = variable=value

    Эквивалент --set-variable variable=value в командной строке. Данный синтаксис необходимо использовать для задания переменных mysqld . Заметьте, --set-variable не используется с MySQL 4.0. Просто используйте --variable=value .

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

Обратите внимание на то, что для параметров и значений все введенные перед ними и после них пробелы автоматически удаляются. В строках значений можно использовать такие экранирующие секвенции: " \b ", " \t ", " \n ", " \r ", " \\ " и " \s " (" \s " - это пробел).

Пример типичного глобального файла параметров:

Port=3306 socket=/tmp/mysql.sock port=3306 socket=/tmp/mysql.sock set-variable = key_buffer_size=16M set-variable = max_allowed_packet=1M quick

Пример типичного файла параметров пользователя:

# Указанный пароль будет направлен всем стандартным клиентам MySQL password=my_password no-auto-rehash set-variable = connect_timeout=2 interactive-timeout

Если у вас дистрибутив исходного кода, то примеры конфигурационных файлов с именами my-xxxx.cnf можно найти в каталоге support-files . В случае бинарного дистрибутива следует обратиться к каталогу DIR/support-files , где DIR - имя каталога установки MySQL (обычно /usr/local/mysql). На данный момент там приведены примеры файлов конфигурации для малых, средних, больших и очень больших систем. Чтобы поэкспериментировать с файлом, можно скопировать my-xxxx.cnf в свой домашний каталог (переименуйте копию в.my.cnf).

Все поддерживающие файлы параметров клиенты MySQL принимают следующие параметры:

Обратите внимание на то, что указанные выше параметры должны идти первыми в командной строке! Однако параметр --print-defaults может использоваться сразу после команд --defaults-xxx-file .

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

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

Настройка некоторых параметров может повысить производительность базы данных в сотни раз!

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

innodb_buffer_pool_size

Если Вы используете только InnoDB таблицы, устанавливайте это значение максимально возможным для Вашей системы. Буфер InnoDB кеширует и данные и индексы. Поэтому значение этого ключа стоит устанавливать в 70%...80% всей доступной памяти.

Innodb_buffer_pool_size = 24G

# При том, что на нашем сервере 32Гб оперативной памяти

innodb_log_file_size

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

Innodb_log_file_size = 512M

# Так два файла дадут размер лога в 2x512M = 1G

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

innodb_log_buffer_size

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

Innodb_log_buffer_size = 2M

# Значения по умолчанию в 1М должно быть достаточно для большинства случаев

innodb_file_per_table

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

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

# С версии 5.6 этот параметр включен по умолчанию

innodb_flush_method

Этот параметр определяет логику сброса данных на диск. В современных системах при использовании RAID и резервных узов, вы будете выбирать между O_DSYNC и O_DIRECT :

Innodb_flush_method = O_DSYNC

# Помните об обязательном использовании резервных узлов (например, реплик)

innodb_flush_log_at_trx_commit

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

Тут следует руководствоваться такой логикой:

  • innodb_flush_log_at_trx_commit = 1 для случаев, когда сохранность данных — это приоритет номер один.
  • innodb_flush_log_at_trx_commit = 2 для случаев, когда небольшая потеря данных не критична (например, вы используете дублирование и сможете восстановить небольшую потерю). В этом случае транзакции будут сбрасываться в лог на диск только раз в секунду.

Устанавливайте значение на свое усмотрение, однако в большинстве случаев подойдет второй вариант:

Innodb_flush_log_at_trx_commit = 2

# Значительное ускорение записи в базу, однако это потребует механизмов дублирования данных

query_cache_size

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

Query_cache_size = 0

# Однако убедитесь, что используете индексы для обеспечения высокой скорости работы запросов

max_connections

Не следует изменять значение этого параметра на старте. Однако, если вы получаете ошибки "Too many connections" , эту опцию стоит поднимать. Она определяет максимальное количество одновременных соединений с базой данных:

Max_connections = 256

# Поднимайте значение постепенно при появлении ошибок соединений

TL;DR

Настройки по умолчанию скорее всего не подойдут. Поэтому обязательно стоит пройтись по указанным параметрам в статье и подобрать для них значения. Если совсем лень — .