Похоже, отлаживать ситуацию придется на уровне модификации запросов из приложения. Как уже упоминалось выше, на момент отладки следует включать и анализировать лог медленных запросов. Где-то дописать индексы, где-то заменить чтение из обычной таблицы на чтение из временной таблицы. Тут же, самим SQL регламентирован инструмент всех времен и народов - EXPLAIN.
Отдельным моментом стоит обратить внимание на блокировки. Часто сталкивался с ситуацией, когда множество запросов на чтение не дают выполняться запросам на запись (или наоборот перегруз запросов на запись блокируют чтение), чем под нагрузкой моментально переполняют очередь - и основное процессорное время расходуется управлением этой очередью. Конкретно из своего опыта (я работал чуть больше года техником в хостинг-конторе), чаще всего проблема проявлялась у сайтов на базе Wordpress. Причем, сам движок Wordpress оптимизирован достаточно хорошо. Проблема в бесконечном количестве плагинов от авторов средней руки. Особенно, плагины, связанные со сбором/подсчетом статистики. При генерации одной страницы используется десятки противоречащих друг-другу запросов на чтение и запись. Бывало, из-за блокировок два одновременно работающих (конкурирующих) инстанса php посылают к БД запросы блокирующие работу друг-друга с такой интенсивностью, что адекватная работа возможна только ограничением их количества одним лишь инстансом php. И никакой переезд на более мощный или облачный сервер не поможет. Логические ошибки решать наращиванием мощностей неэффективно и может быть очень дорого. - А потому любое наращивание мощностей железа - есть решение временное, и способно отсрочить работы по отладке максимум на несколько дней. В проектировании приложений (как web/rest, так и standalone) надо понимать что делает каждый action - либо он пишет в БД, либо читает из БД. Если каждый action будет требовать много чтений и записей в одних и тех же таблицах, это обязательно приводит к проблемам блокировок.
Тулзами для анализа событий io для решения проблем mysql пользоваться бесполезно - mysql достаточно хорошо контролирует использование io не доводя ядро до перегрузок. Но, и опять же предоставляет множество настроек для несистемных ограничений, которые могут быть установленны неэффективно и проблему можно решить скорректировав их.
И еще мысль ради пищи для размышлений - во большинстве ситуаций таблицы MyISAM работают в разы быстрее InnoDB.
