Я сделаю все возможное, чтобы помочь здесь. Отчет MysqlTuner подразумевает, что у вас есть 4 ГБ ОЗУ в этом VPS, поэтому мои предложения основаны на этом.
query_cache_size - это объем оперативной памяти, которую MySQL может использовать для кэширования результатов запросов к базе данных. Результаты, хранящиеся в кэше запросов, возвращаются намного быстрее, чем обычные операции выбора, поэтому эта переменная может значительно ускорить процесс (в большей степени, чем любые другие предлагаемые изменения).
Именно то, что правильное значение для вас, потребует некоторых экспериментов. В настоящее время у вас есть этот набор до 8M. Если у вас есть 4 ГБ оперативной памяти в этом окне, я бы начал с 64 МБ, увеличившись до 128 М, а затем, если потребуется, до 256 МБ После каждого изменения оставьте вещи на несколько дней, а затем снова запустите MysqlTuner и сравните процент «эффективности кэширования запросов» с тем, что было раньше. Для сервера, на котором в основном размещено 5 блогов Wordpress, я сомневаюсь, что вы увидите улучшение за пределами 256M, и я бы не рекомендовал выходить за рамки одной восьмой от общего объема ОЗУ.
Лично я нахожу Munin (бесплатный инструмент мониторинга сервера) весьма удобным для отслеживания такого рода вещей, поскольку он будет отображать попадания в кэш по сравнению с другими запросами.
tmp_table_size - для некоторых сложных запросов (особенно тех, которые используют GROUP BY или сложную сортировку), MySQL должен сначала создать временную таблицу, содержащую данные, а затем выполнить некоторые операции над ней, чтобы создать результат задавать. Он попытается создать эти временные таблицы в памяти, поскольку это намного быстрее, чем создание их на диске; но для больших наборов результатов это не всегда возможно. tmp_table_size контролирует этот порог.
Я не могу себе представить, что Wordpress выполняет какие-то чрезвычайно сложные запросы, поэтому я бы не стал зацикливаться на этом. MysqlTuner предлагает значение, превышающее 32 МБ, поэтому начните с 64 МБ и посмотрите, как это повлияет на значение «Временные таблицы, созданные на диске», через несколько дней. Установите max_heap_table_size, пока вы на нем, как это предлагается.
thread_cache_size - Wordpress не использует постоянные соединения по умолчанию (что хорошо), поэтому каждый запрос устанавливает новое соединение с вашей базой данных, а затем закрывает его после создания страницы. Эти издержки не значительны, но использование thread_cache_size позволяет MySQL повторно использовать эти потоки соединения, что немного поможет.
Я бы пошел с предложенным значением 4, которое, я думаю, подойдет, если вы не получите большое количество одновременных пользователей.
table_cache - Я немного запутался, похоже, это связано с кэшем MySQL структуры таблицы. Я бы пошел с 128 для этого.
innodb_buffer_pool_size - это объем памяти, который MySQL может использовать для кэширования индексов и данных для таблиц InnoDB. Это немного озадачивает меня, так как я не думаю, что Wordpress вообще использует InnoDB - есть ли у вас другие сайты на этом сервере?
Чтобы ответить на другие ваши вопросы, конфигурация после [mysqld_safe] применяется только к демону MySQL в безопасном режиме, а не к MySQL в целом, поэтому некоторые переменные дублируются. Если вы измените innodb_buffer_pool_size, вы захотите изменить первый. Переменные, которых нет в файле, вы можете добавить, но добавьте их над блоком [mysqld_safe] по той же причине.
И наконец, поскольку вы настроены на оптимизацию, если вы еще не используете кеш байт-кода PHP, такой как APC , то это стоит изучить. APC может значительно улучшить скорость работы PHP-приложений без каких-либо негативных последствий.