Лучшие практики оптимизации баз данных MySQL

Question

Каковы оптимальные методы оптимизации установки MySQL для достижения максимальной производительности при обработке таблиц более больших размеров (> 50 тыс. Записей с общим объемом около 100 МБ на таблицу)? В настоящее время мы пытаемся переписать DelphiFeeds.com (новостной сайт для сообщества программистов Delphi) и заметили, что простые операторы Update могут занимать до 50 мс. Это похоже на многое. Существуют ли рекомендуемые параметры конфигурации, которые мы должны включить / установить, которые обычно отключаются при стандартной установке MySQL (например, чтобы использовать больше ОЗУ для кэширования запросов и данных и т. Д.)?

Кроме того, какое влияние на производительность оказывает выбор механизмов хранения? Мы планируем использовать InnoDB, но если MyISAM рекомендуется из соображений производительности, мы можем использовать MyISAM.

Answer 1

«Лучшая практика» - это:

1. Измерьте производительность, изолируя соответствующую подсистему, насколько это возможно.
2. Определите причину узкого места. Вы связаны с I / O? Процессор связан? Память связана? Ожидание на замках?
3. Внесите изменения, чтобы устранить первопричину, которую вы обнаружили.
4. Измерьте еще раз, чтобы продемонстрировать, что вы устранили узкое место и на сколько .
5. Перейдите к шагу 2 и, при необходимости, повторяйте, пока система не заработает достаточно быстро.

Подпишитесь на канал RSS на http://www.mysqlperformanceblog.com и читайте его исторические статьи тоже. Это чрезвычайно полезный ресурс для мудрости, связанной с производительностью. Например, вы спрашивали о InnoDB против MyISAM. Их вывод: производительность InnoDB в среднем на 30% выше, чем у MyISAM. Хотя есть и несколько сценариев использования, в которых MyISAM превосходит InnoDB.

• Тесты InnoDB и MyISAM против Falcon - часть 1

Авторы этого блога также являются соавторами "High Performance MySQL", книги, упомянутой @Andrew Barnett.

---

Комментарий от @ uıu: Как определить, зависит ли ваш ввод-вывод от процессора или от памяти, зависит от платформы. Операционная система может предлагать такие инструменты, как ps, iostat, vmstat или top. Или вам может потребоваться сторонний инструмент, если ваша ОС его не предоставляет.

По сути, любой ресурс, привязанный к 100% использованию / насыщению, скорее всего, станет вашим узким местом. Если ваша загрузка процессора низкая, но ваша нагрузка ввода-вывода максимальна для вашего аппаратного обеспечения, то вы привязаны к вводу-выводу.

Однако это всего лишь одна точка данных. Средство может также зависеть от других факторов. Например, сложный запрос SQL может выполнять сортировку файлов, и это делает ввод-вывод занятым. Стоит ли использовать на нем более / более быстрое оборудование или изменить дизайн запроса, чтобы избежать сортировки файлов?

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

---

Джефф Этвуд только что написал хорошую статью в блоге о поиске узких мест в системе:

• Компьютерная игра Shell Performance

Answer 2

Купите «High Performance MySQL» у О'Рейли. Это почти 700 страниц по этой теме, поэтому я сомневаюсь, что вы найдете краткий ответ по SO.

Answer 3

Сложно разбираться с вещами, но возможен умеренно высокий уровень просмотра.

• Вам необходимо оценить отношения чтения: записи. Для таблиц с соотношениями ниже, чем примерно 5: 1, вы, вероятно, выиграете от InnoDB, потому что тогда вставки не будут блокировать выборки. Но если вы не используете транзакции, вы должны изменить innodb_flush_log_at_trx_commit на 1, чтобы вернуть производительность по сравнению с MyISAM.
• Посмотрите на параметры памяти. Стандартные настройки MySQL очень консервативны, и некоторые ограничения памяти могут быть увеличены в 10 и более раз даже на обычном оборудовании. Это принесет пользу вашим выборам, а не вставкам.
• MySQL может регистрировать такие вещи, как запросы, которые не используют индексы, а также запросы, которые занимают слишком много времени (определяется пользователем).
• Кеш запросов может быть полезен, но вам нужно его обработать (то есть посмотреть, насколько он используется). Кактусы могут это сделать; как может Мунин.
• Дизайн приложения также важен:
  • Слабое кэширование часто извлекаемых, но небольших наборов данных будет иметь большое различие (то есть время жизни кэша в несколько секунд).
  • Не перечитывайте данные, которые вам уже нужно передать.
  • Многоэтапное хранение может помочь с большим объемом вставок в таблицы, которые также активно читаются. Основная идея заключается в том, что у вас может быть таблица для специальных вставок (INSERT DELAYED также может быть полезна), но пакетный процесс для перемещения обновлений в MySQL оттуда, куда происходят все чтения. Есть варианты этого.
• Не забывайте, что перспектива и контекст тоже важны: то, что вы думаете, что UPDATE может произойти очень долго, может быть довольно тривиальным, если это "длинное" обновление происходит только один раз в день.

Answer 4

Существует множество лучших практик, которые уже обсуждались ранее, поэтому нет смысла их повторять. Чтобы получить конкретный совет о том, что делать, я бы попробовал запустить MySQL Tuner . Это Perl-скрипт, который вы можете скачать и затем запустить на своем сервере базы данных, он предоставит вам кучу статистических данных о том, как работает ваша база данных (например, попадания в кэш), а также некоторые конкретные рекомендации для решения проблем или параметров конфигурации улучшить производительность.

Хотя все эти статистические данные доступны в самом MySQL, я считаю, что этот инструмент предоставляет их гораздо проще для понимания. Хотя важно отметить, что YMMV в отношении рекомендаций, я считаю, что они в целом довольно точны. Просто убедитесь, что вы хорошо поработали над базой данных заранее с реалистичным трафиком.