Какие параметры конфигурации для MySQL обеспечивают наибольшее улучшение скорости?

Какие параметры конфигурации для MySQL обеспечивают наибольшее улучшение скорости?

Меня интересует фактические улучшения файлов конфигурации, типы таблиц, настройки оборудования, репликация и т. Д. Что-нибудь, кроме структуры запросов и структуры таблиц (их легко найти на веб-сайте и в переполнении стека). Такие вещи, как настройки кэша запросов, дали вам наибольшую скорость? Как насчет дисков; лучше иметь его на внешнем RAID или на внутреннем? Дала ли вам репликация лучшую производительность, особенно при чтении больших запросов?

Какие другие настройки / изменения вы внесли для улучшения производительности MySQL?

Примечание: я понимаю, что они очень зависят от использования (то есть, маленький веб-сайт или хранилище данных), но, как я думаю, большинство из нас, вероятно, работают на различных сайтах / системах, было бы хорошо знать множество методов, которые могут применяться к различным ситуации. Кроме того, я думаю, что некоторые методы могут быть переданы между ситуациями.

Вот мои рекомендации (ваш расход может варьироваться)

• Используйте аппаратный RAID. Это идет вразрез с моими рекомендациями использовать программный RAID в других постах, однако это специфическая ситуация, когда вам нужна аппаратная карта RAID. В частности, вы хотите, чтобы NVRAM с резервным питанием от батареи на карте RAID сокращал время, необходимое для передачи файла журнала на диск.
• Используйте ТОЛЬКО RAID 1 или RAID 10 томов. Стоимость записи RAID 5 или 6 слишком высока, чтобы выдерживать смешанную нагрузку чтения / записи.
• Используйте отдельные LUN ​​для данных, журналов и томов TMP. Все они должны быть отделены от операционной системы и томов подкачки.
• Используйте InnoDB .
• Используйте innodb_file_per_table
• Используйте 64-битную ОС
• Установите буферный пул InnoDB на ~ 80% доступной оперативной памяти
• Установите для ваших файлов журналов 1/4 размера пула буферов, от 2 до 4 файлов журналов. Большие файлы журнала означают более медленное время выключения и восстановления, но позволяют быстрее восстанавливать большие дампы базы данных.
• log_slow_queries, log-query-not-using-indexes, set-variable = long_query_time = 1, исследует каждый запрос в этом журнале, реорганизует вашу схему, чтобы по возможности избегать сканирования таблиц и таблиц tmp.

Еще раз Дэйв Чейни действительно выбил его из парка здесь. Я действительно не могу ничего добавить к его ответу на ваш вопрос. Тем не менее, я хотел бы указать на то, что вы не спрашивали. Как научили меня Джереми Заводный и Питер Зайцев много лет назад, ваш ROI за время, потраченное на отслеживание и оптимизацию некорректных запросов, превзойдет ваш ROI за время, потраченное на внесение изменений в конфигурацию в 10 раз. Конечно, вы не хотите иметь плохую конфигурацию, неправильную настройку RAID или недостаточно оперативной памяти. Но среди отличных и даже незначительных, плохие запросы администраторов баз данных MySQL (обычно от разработчиков / платформ, а не администраторов баз данных) - это хроническое состояние, при котором плохая конфигурация является долговременной .

(Я выкопал эти прилагательные некоторое время и до сих пор не доволен теми, которые я выбрал.)

Я хотел бы еще раз подчеркнуть, что если ваши разработчики используют ORM, подобный распространенному в таких средах, как Ruby on Rails и Django, вы ДЕЙСТВИТЕЛЬНО ДОЛЖНЫ отслеживать запросы, попадающие в вашу БД. Когда разработчики перестают думать о SQL и позволяют абстрагироваться от БД, это очень неприятно. Мне нравятся две платформы, которые я только что упомянул. (Не опровергайте меня за плохие слова.) Это просто делает Query Sleuthing очень важным. (Читать: Безопасность работы)

Несколько других вещей (которые не были упомянуты в ответе Дейва Чейни)

• Попробуйте установить innodb_flush_method в O_DIRECT, чтобы избежать двойной буферизации данных. Избегайте этого, если на вашей карте RAID нет кэша записи с резервным питанием от батареи или ваши данные находятся в сети SAN.

• Также играйте с innodb_thread_concurrency. Я полагаю, что по умолчанию установлено значение 8, но стоит изменить это, чтобы увидеть, улучшает ли это производительность

• Убедитесь, что кеш запросов включен и проверьте статистику, чтобы увидеть, какова частота попаданий. Если это хорошо, попробуйте увеличить его, чтобы увидеть, улучшает ли он рейтинг попаданий.

• В зависимости от запущенных приложений вы можете изменить уровень изоляции по умолчанию. По умолчанию установлено значение REPEATABLE_READ, но READ_COMMITTED может повысить производительность.

• Если ваши операторы в основном представляют собой ОБНОВЛЕНИЯ и УДАЛЕНИЯ, вы можете попробовать заполнить кэш на ведомом устройстве, выполнив запрос SELECT, который возвращает набор результатов, который необходимо изменить. Проверьте инструмент mk-slave-prefetch , который сделает это за вас

• Взгляните на другие механизмы хранения, кроме MyISAM и InnoDB

Ничего не могу сказать об оборудовании, но вы можете попробовать http://blog.mysqltuner.com . Это скрипт Perl, который анализирует ваши настройки MySQL.

Вы можете увидеть пример выходных данных на http://www.thomas-krenn.com/de/wiki/MySQL_Performance_Tuning#mysqltuner.pl

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

Следующее, что вы должны сделать, это посмотреть на кеш таблицы. Значение по умолчанию - 64, что полезно, только если у вас не более 60 таблиц. Вы будете хотеть поднять это долгий путь.

Третье, что вы должны сделать, это посмотреть на поток и параметры соединения. Значение по умолчанию wait_timeout очень велико для большинства веб-приложений и может быть уменьшено до 30 секунд. Это также улучшит использование памяти, так как MySQL будет быстрее собирать соединения, оставляя гораздо меньше в состоянии сна.