Оптимизация mysql очень хорошо прокомментирована в сети, и вы найдете огромную информацию о том, как это сделать.Никогда не существует «лучших параметров», лучшие параметры - это те, которые соответствуют вашим потребностям, аппаратное обеспечение коробки, использование mysql… Итак, я не буду давать лучшие параметры, а скорее, как определить эти параметры.Проведите несколько тестов, и вы быстро найдете свои собственные параметры.
Существует множество доступных параметров, но очень немногие из них очень важны для настройки вашего mysql-окна.
Наиболее важные переменные(для меня это не является исчерпывающим):
- max_connections
- wait_timeout
- thread_cache_size
- table_cache
- key_buffer_size
- query_cache_size
- tmp_table_size
Чтобы получить статистику вашего сервера mysql с момента его загрузки, запустите mysqladmin processlist extended-status, как упомянуто выше.
1 - Две наиболее важные переменные: Table_cache и Key_buffer_size
- Если Opened_tables большой, то ваша переменная table_cache, вероятно, слишком мала.table_cache 64 Open_tables 64 Opened_tables 544468
Это первая серьезная проблема.«Table_cache - это число открытых таблиц для всех потоков. MySQL, будучи многопоточным, может одновременно выполнять много запросов к таблице, и каждый из них откроет таблицу».Поэтому, хотя у нас всего несколько таблиц, нам понадобится еще много open_tables.
Значение Opened_tables велико и показывает количество пропусков кэша.Получение правильного размера table_cache - одна из двух лучших вещей, которые вы можете сделать для повышения производительности.
- Если Key_reads велик, то ваша переменная key_buffer_size, вероятно, слишком мала.Частота попаданий в кэш может быть рассчитана с помощью Key_reads / Key_read_requests.key_buffer_size 16M Key_read_requests 2973620399 Key_reads 8490571 (частота попаданий в кэш = 0,0028)
«Параметр key_buffer_size влияет на размер буферов индекса и скорость обработки индекса, особенно чтения.» Руководство MySQL (и другие источники) говорят, что «отношение Key_reads / Key_read_request обычно должно быть <0,01». Это еще одна важная вещь для получения правильного значения. Здесь значение кажется правильным (<0,01) </p>
Также проверьте key_write_requests и key_writes.key_writes / key_writes_request обычно должен быть <1 (около 0,5, кажется, хорошо) </p>
Вот очень интересный веб-указатель: table_cache и key_buffer_size
2 - другие важные настройкиявляются: Wait_timeout, max_connexion, thread_cache
Небольшое объяснение: Вообще у вас есть много процессов mysql, которые спят, потому что wait_timeout не установлен на низкое значение. Поэтому я удостоверяюсь, что wait_timeout установлендо очень низкого значения: 15 секунд (для меня).t означает, что MySQL закроет любое соединение, которое было бездействующим более 15 секунд.
Проблема в том, что вам также нужно увеличить max_connexion (у меня установлено значение 300), чтобы убедиться, что не много неактивных клиентовудержание связей и блокирование новых клиентов от соединения и получения реальной работыPBM заключается в том, что коробка должна создавать новые потоки (MySQL - многопоточный сервер) с очень высокой скоростью.Это может высосать измеримое количество процессорного времени.
Таким образом, решение состоит в том, чтобы использовать Thread_cache (из документа mysql): «Сколько потоков мы должны хранить в кэше для повторного использования.Когда клиент отключается, клиентские потоки помещаются в кэш, если ранее не было потоков, превышающих thread_cache_size.Все новые потоки сначала извлекаются из кэша, и только когда кэш пуст, создается новый поток.Эта переменная может быть увеличена для повышения производительности, если у вас много новых подключений.(Обычно это не дает заметного улучшения производительности, если у вас есть хорошая реализация потоков.) Изучив разницу между Connections и Threads_created, вы можете увидеть, насколько эффективен для вас текущий кэш потоков. ”
- Если Threads_created велико, вы можете увеличить переменную thread_cache_size.Частота попаданий в кэш может быть рассчитана с помощью Threads_created / Connections.thread_cache_size0 Threads_created 150022 Соединения 150023
Это вторая проблема, которая должна быть исправлена.Нулевой размер кеша является значением по умолчанию для my-medium.cnf, но рекомендуемый размер в my-large.cnf равен 8.
. Вы можете попробовать эту формулу: table_cache = открытая таблица / max_used_connection
3 - Наконец, вы также можете взглянуть на: tmp_table_size и Handler_read_rnd / Handler_read_rnd_next
- Если Created_tmp_disk_tables велико, вы можете увеличить переменную tmp_table_size, чтобы получить временную переменнуютаблицы память на основе вместо диска на основе.
tmp_table_size 32M Created_tmp_disk_tables 3227 Created_tmp_tables 159832 Created_tmp_files 4444
Created_tmp_disk_tables является "числом неявных временных таблиц на диске, которая создается во время выполнения операторов" и Created_tmp_tablesоснованы на памяти.Очевидно, это плохо, если вам нужно перейти на диск вместо памяти.Около 2% временных таблиц попадают на диск, что не так уж и плохо, но увеличение tmp_table_size, вероятно, тоже не повредит.
- Если Handler_read_rnd большой, то у вас, вероятно, много запросовкоторые требуют MySQL для сканирования целых таблиц или у вас есть объединения, которые не используют ключи должным образом.Handler_read_rnd 27712353 Handler_read_rnd_next 283536234
Эти значения высоки, и мы, вероятно, сможем улучшить индексы и запросы.
Я надеюсь, что это поможет некоторым из вас лучше понять, как это происходитможно оптимизировать MYSQL под свои нужды, аппаратную часть или текущее использование mysql.