Посоветуйте хостинг с большим Update-запросов к MySQL

Возможно, это как раз тяжелый путь. Ну там, кмс - "ас ис".

8000/час = 192к в сутки

192000 - 200 = боты => многастраниц?

175000/8000 = 21,875 апдейт запросов на документ?

"Чета нада" делать!

Вам уже не шаред искать надо, а минимум виртуальный сервер, с таким кол-вом запросов к БД, причём с не менее пары ядер CPU и 4 Гб. ОЗУ.

Делать, программиста нанимать и разбираться, что там фигачит такое количество запросов.

Все ограничения MySQL кроме одновременных соединений не нужны. Нет ничего плохого, чтобы сделать миллион UPDATE-запросов в час. Если запросы и таблицы оптимизированы, запросы будут выполняться быстро и не будут грузить MySQL-сервер.

Ищите хостинг в РФ без ограничений на количество соединений/запросов к MySQL в час. Лимитировать количество одновременных соединений - норма.

Может объясните мне с какой поры количество запросов стало показателем нагрузки?

Один запрос UPDATE, делающий SET +1, с выборкой по ID (рандомное значение), в таблице из 650 тысяч записей выполняется за 0.075 ms (зависит от настроек сервера и процессора).
Да, 75000 наносекунд. Вам жалко что ли? У меня пинг от компьютера до роутера с патчкордом в 5 раз больше. Эти 175 тысяч запросов UPDATE залетают со свистом за 13 секунд, из них затрачено конкретно на работу CPU еще меньше.

А теперь представьте, что у клиента именно такие небольшие запросы. Нафига ему VPS? 😀

Вспомним теперь, что ограничение 175 тысяч запросов за ЧАС, и если представить что 13 секунд это чисто затраченное CPU время и разбить на 60 минут, то 13/60 = 0.216 секунды CPU-времени в минуту. Сами PHP скрипты съедают процессора, как правило, в несколько раз больше.

Пусть сразу дата-центр свой строит, чего уж там.

и правда, что то вы перегнули

на этом шаред-хостинге размещено 2 сайта

и этих параметров мне хватает. с запасом в несколько раз

Такой апдейт без записи - да, ибо в памяти это изменение не особо пишет. Как только в диск пишет сразу 75000 наносекунд превратятся в мили, а то и просто секунды.

Далее. в Таблице 500к записей? или 15к записей? Разница огромная. Если 500к жирных записей, то хостер врядли дб серверу выделит гигабайты памяти под сайтик за 50 рублей в месяц.

Все зависит от настроек безопасности данных и скорости самой системы. Как бы не хотели, а на hdd сделать тоже что на ssd или nvme нельзя

Если произвести запись с AUTOCOMMIT (175 тысяч транзакций InnoDB), то будет уже 110000 наносекунд при innodb_flush_log_at_trx_commit 2 на SSD  :)

Я понимаю, что результаты будут у всех разные. Единственное, что я хотел сказать, что предлагать ТСу перейти на VPS-хостинг, опираясь только на количество запросов, выглядит довольно безосновательно. Это как если бы ТС сказал: "У меня 5000 уников в день на сайт заходят", а кто-нибудь ему посоветовал перейти на VPS. При этом нет никакой информации о скриптах, оптимизации, никакой конкретики, может там вообще сайт на html (просто для примера, к реальному ТСу отношения не имеет).

Один запрос с кучей JOIN'ов к большим таблицам без индексов может натворить дел похуже, чем большое количество апдейтов за час.

Все это нужно смотреть индивидуально, если от клиента поступает реальная нагрузка. Вот ТС-у даже не писали с хостинга о нагрузке, его просто автоматические ограничения защемили.

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

Панель управления ISPmanager не считает нагрузку на MySQL сервер, т.е. такой статистики Вы в ней не увидите, здесь только нагрузка на сам сервер от исполнения Ваших скриптов.