Alexs47

Не получится, наверное, объяснить много, но хотя бы начну.
1) Включить логгирование медленных запросов в БД
2) Есть такая команда - EXPLAIN - https://dev.mysql.com/doc/refman/8.0/en/using-expl...
Помогает понять как SQL-запрос должен работать
3) Индексами злоупотреблять тоже не надо. Обычно имеет смысл ставить индекс на поле в двух случаях: либо по этому полю связываются таблицы в JOIN'е, либо по нему происходит поиск. Больше индексов - больше потребление памяти.
4) Обычно настройка базы данных по моему опыту в итоге приходит к эмпирическому подбору размеров буферов и так далее, поскольку часто зависит от того, какие данные хранятся в базе и как обрабатываются
5) Все запросы надо посмотреть на предмет JOIN'ов и проанализировать при помощи EXPLAIN. Если две таблицы связаны по каким-то полям, не факт, что связывание будет в том направлении, в котором вы думаете. Тут на самом деле очень помогает построить схему SQL-запроса с таблицами и связями.
6) Иногда для того, чтобы индекс заработал, может потребоваться немного поменять SQL-запрос, зависит от БД и от планировщика запросов. Иногда помогает переписать запрос в обратном направлении или просто изменив порядок таблиц при связывании.
И т.д.
Я в данный момент решаю проблемы похожие вашим, но на PostgreSQL, принципы все те же. Иногда время выполнения запросов удается уменьшить до 15000 раз (на больших базах)

Ну во первых смотрите, сколько у вас неудачных соединений с БД - аж 66 штук. На нормальном проекте такого в принципе не должно быть. Наводит на мысль, что внутри проекта есть неоптимальные запросы или некорректно составленные, которые подвисают в момент нагрузки и не дают нормально подключаться другим. Это и объясняет подвисание PMA скорее всего - он банально не может подключиться к СУБД. И видимо это настолько печально, что даже ваших 2 тыс разрешенных подключений не хватает. Эти запросы можно отследить в самом MySQL, в консоли лучше всего командой SHOW FULL PROCESSLIST; - впрочем если будет нагрузка, скорее всего даже в консоль не сможете подключиться. Но если при нормальной работе сайта у вас там будет десяток подвисших запросов - явно дело пахнет не очень хорошо.
Смотрите еще Low Query - цифра тоже большая. Вам надо просмотреть эти запросы и определиться, что именно можно там изменить. В некоторых случаях достаточно сделать индекс на поле в таблице, чтобы в разы ускорить обработку запроса. А в некоторых нужно оптимизировать код приложения уже, чтобы заменить длинный запрос на более короткий и быстрый. Включите хотя бы временно логирование этих запросов в отдельный лог и разберите каждый из них.
Еще остается вопрос - что больше грузит CPU - именно MySQL или все же код приложения? На чем оно написано, фреймворк, CMS какие - все это нужно учитывать.