Как это ни парадоксально, уменьшение количества соединений обычно повышает производительность.Соединения в пуле - это повторно используемые ресурсы, и существует очередь запросов на подключение.Таким образом, вместо того, чтобы пытаться выполнять много запросов одновременно, СУБД будет обрабатывать меньшее количество запросов одновременно и обрабатывать загрузку последовательно.
Так что для запросов, подобных вашему, которые должны выполняться в течение короткого времени, создайте пул с небольшим значением connectionLimit.Попытка 10. Если это работает хорошо, попробуйте 5.
Если у вас есть другие запросы, которые занимают больше времени, вам может потребоваться другой пул соединений для них.
Не говоря уже о том, что приложение кластеризованного узлаоткроет это количество соединений для каждого члена кластера.400 соединений - это слишком много для почти всех развертываний MySQL.(Если у вас есть развертывание, которое обрабатывает сотни соединений, ваш менеджер по закупкам знает об этом, потому что такие развертывания стоят очень дороже.)
Однако у вас может быть эта проблема: если миллионыпользователи обновляют точно такую же строку msgId = 10
, у вас будет состязание СУБД в этой строке.В этом случае вы можете сохранить количество попаданий в строку, а затем выполнять UPDATE... SET count = count + n
один раз в несколько секунд, а не при каждом попадании.