Оптимальная конфигурация MySQL (my.cnf)

Question

Ниже приведен мой рабочий файл конфигурации MySQL по умолчанию (my.cnf) для настройки чистого UTF-8 с InnoDB в качестве механизма хранения по умолчанию.

[server]
bind-address=127.0.0.1
innodb_file_per_table
default-character-set=utf8
default-storage-engine=innodb

Настройка выполняет следующее:

1. Привязывается к localhost:3306 (loopback) вместо значения по умолчанию *:3306 (все интерфейсы).Сделано для повышения безопасности.
2. Настраивает одно табличное пространство для каждой таблицы.Сделано для повышения ремонтопригодности.
3. Устанавливает набор символов по умолчанию равным UTF-8.Сделано для обеспечения легкой интернационализации по умолчанию.
4. Устанавливает механизм хранения данных по умолчанию в InnoDB.Сделано для того, чтобы разрешить блокировку на уровне строк по умолчанию.

Предположим, что вы могли бы еще больше улучшить настройку, добавив максимум три (3) параметра конфигурации.Что бы вы добавили и почему?

Улучшение в этом контексте означало бы либо повышение производительности, либо повышение надежности, либо повышение простоты использования / удобства обслуживания.Вы можете предположить, что машина, на которой запущен экземпляр MySQL, будет иметь 1000 МБ оперативной памяти.

Answer 1

Чтобы кэшировать больше данных:

innodb_buffer_pool_size = 512M

Если вы записываете много данных:

innodb_log_file_size = 128M

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

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

Answer 2

Выделение InnoDB большего объема памяти, чем 8M по умолчанию (с использованием innodb_buffer_pool_size), безусловно, является улучшением.Что касается значения, то на выделенном сервере баз данных, таком как ваш, вы можете установить его на уровне 80% вашей оперативной памяти, и чем выше вы установите это значение, тем меньше будет взаимодействий с жестким диском.Просто чтобы отдать свои два цента, я хотел бы упомянуть, что вы можете добиться некоторого повышения производительности, изменив значение innodb_flush_log_at_trx_commit, однако принося в жертву соответствие требованиям ACID...В соответствии с руководство по MySQL:

Если значение innodb_flush_log_at_trx_commit-это 0, буфер журнала записывается в файл журнала один раз в секунду и сброс для дисковых операций осуществляется на файл журнала, но ничего не делается в фиксации транзакции.

Таким образом, вы можете потерять некоторые данные, которые не были должным образом записаны в базу данных из-за сбоя или какой-либо другой неисправности.Опять же в соответствии с руководством MySQL:

Однако аварийное восстановление InnoDB не затронуто и, следовательно, аварийное восстановление работает независимо от значения.

Итак, я бы предложил:

innodb_flush_log_at_trx_commit = 0

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

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

Answer 3

Увеличьте размер буферного пула innodb настолько, насколько это практически возможно:

innodb_buffer_pool_size=768M

Вам также понадобится некоторое пространство в буфере ключей для временных таблиц:

key_buffer_size=32M

Другие будут зависеть от того, что вы делаете с базой данных, но table_cache или query_cache_size были бы парой других возможностей.