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

ниже приведен мой файл конфигурации 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 МБ ОЗУ.

9
innodb my.cnf mysql optimization utf-8

3 ответов

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

innodb_buffer_pool_size = 512M

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

innodb_log_file_size = 128M

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

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

5

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

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

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

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

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

innodb_flush_log_at_trx_commit = 0

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

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

1

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

innodb_buffer_pool_size=768M

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

key_buffer_size=32M

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

0