Я ищу краткий список общий подводные камни и оптимизации для настройки сервера MySQL, используемого для веб-сайтов среднего размера.
В общем, тип совета, который я ищу здесь, - это информация, которую может легко реализовать обычный разработчик или администратор, которая принесет ощутимую пользу производительности его сайта.
Например
Вот совет, который я почерпнул из чтения Высокая производительность MySQL которые я часто использую для:
При использовании механизма хранения MyISAM (по умолчанию) сервер блокирует всю таблицу при выполнении операции DELETE или UPDATE или при выполнении INSERT, который не добавляется в конец таблицы (потому что от предыдущее УДАЛИТЬ). Никакие другие запросы не могут использовать эту таблицу до завершения операции.
Следовательно, вы должны использовать InnoDB или другие механизмы блокировки на уровне строк для любой часто используемой таблицы, если она видит много изменений с использованием любой операции, кроме «INSERT».
Вот несколько вещей, с которыми я столкнулся при оптимизации MySQL:
Если вы видите, что ваш сервер базы данных (в частности, процессы MySQL) используют большую часть процессорного времени, это, вероятно, означает, что вам либо не хватает индексов, либо вам нужно оптимизировать запросы.
Включите ведение журнала медленных запросов и выполняйте эти медленные запросы, чтобы узнать, как их можно оптимизировать. Используйте «объяснить» с медленными запросами, чтобы узнать, почему они медленные. В документации MySQL есть несколько разделов о том, как интерпретировать эти результаты.
Используйте memcached для кеширования результатов любых запросов, сколько сможете. Это очень быстро и позволяет кэшировать многие вещи, которые внутреннее кэширование запросов MySQL не может, но может использоваться только в тех случаях, когда вы знаете, что данные можно кэшировать долгое время, или вы вручную истекаете сроком действия кеша.
Настройте "munin" в системе базы данных, чтобы начать сбор информации об использовании системы и загрузке запросов к базе данных.
Убедитесь, что в вашей системе достаточно ОЗУ, чтобы вы не меняли местами, и, надеюсь, достаточно, чтобы вы делали мало, если вообще считываете диск (используйте vmstat или munin для отслеживания этого). Это означает, что данные обслуживаются из MySQL или дисковых буферных кешей.
Шон
Одна вещь, которая может отрицательно повлиять на производительность MySQL, - это создание временных таблиц на диске.
Вы можете запустить это в течение нескольких минут:
mysqladmin -u root -p ext -ri 30 | grep Created_tmp_disk
и если число велико и растет, вы можете рассмотреть возможность размещения MySQL tmpdir в файловой системе на основе ОЗУ (например, tmpfs).
В некотором смысле это может быть лечение симптома, а не причины, но это может обеспечить некоторое быстрое облегчение, пока вы решаете, следует ли и как лечить причину. Следующая ссылка предоставляет информацию о том, как MySQL использует внутренние временные таблицы:
http://dev.mysql.com/doc/refman/5.0/en/internal- Contemporary-tables.html
Ура
Это не совсем по теме, но оптимизация только MySQL не обязательно приведет к оптимизации производительности сайта. То, что вы описали выше, - лишь один из миллионов возможных. Часто ли это случается в вашем веб-приложении? Как именно эта функция MyIssam замедляет работу вашего веб-сайта? (Учитывая, что MyIssam в десятки и сотни раз быстрее InnoDB). Как вы узнали, что это ваш случай?
По сути, ваш вопрос не имеет смысла, пока вы не профилируете свое приложение и не найдете узкое место. В противном случае некоторые общий советы будут противоречить друг другу.
Более того, оптимизация производительности обычно сводится к компромиссам. Вам придется пожертвовать одной оптимизацией ради другой.
Вот хорошая статья для начала: http://www.flounder.com/optimization.htm
Речь идет не о MySQL и не о веб-приложениях, а об оптимизации.
Всем отличных советов. Еще один лакомый кусочек, который я добавлю, - иногда имеющихся у вас индексов недостаточно. Вы можете подумать, что добавления индекса с наиболее запрашиваемыми строками достаточно, но порядок, в котором они находятся в индексе, сильно влияет на производительность. Особенно для InnoDB, который пытается получить нужные данные из индекса, не получая самой строки (например, поиск по диску). Если у вас есть особенно большая таблица, которая запрашивается почти одинаково двумя способами, полезно иметь индекс для точного порядка поиска для обоих типов запросов. Вам это может показаться излишним, но на самом деле это подталкивает оптимизатор в правильном направлении :)
Кроме того, переменные сервера, "нестандартный" файл MySQL my.cnf никогда не подходят. Он очень полезен, чтобы потратить некоторое время на изучение его содержимого и корректировку значений в зависимости от конфигурации вашего оборудования и типов запросов, которые вы получаете чаще всего.
@TechieGurl, вы ошибаетесь в поиске условий в вашем заказе. Это было исправлено в ранней версии 4.x. Оптимизатор запросов задействует ряд показателей и будет использовать ключ, который соответствует наиболее постоянным условным операторам, условным операторам с ранжированием и т. Д., А также будет перемешивать параметры в зависимости от порядка, предполагая, что SQL не содержит порядок приоритета, который может исключать такие оптимизация.
MyISAM ответит на результаты ключа, InnoDB обычно не будет и блокирует строку при ответе как часть соответствия ACID и является скорее конструктивным, чем ошибочным.
проверять, выписываться http://blog.mysqltuner.com/
MySQLTuner - это сценарий, написанный на Perl, который поможет вам с настройкой MySQL и даст рекомендации по повышению производительности и стабильности: http://github.com/rackerhacker/MySQLTuner-perl