Быстрый способ выполнения хранимых процедур MySQL в Java в нескольких потоках?

Немного подумав, кажется, что если у вас возникли проблемы с этим кодом инфраструктуры, ваши проблемы в другом месте. Большинство приложений не занимают слишком много времени, делая это. Убедитесь, что вы используете DataSource, большинство из них кэширование соединений, а некоторые даже кэшируют заявления.
Кроме того, для этого, чтобы быть шеей бутылки производительности, это означало бы, что вы делаете много запросов один за другим или что ваш пул соединений слишком мал. Возможно, вам нужно провести сравнительный анализ своего кода, чтобы узнать, сколько времени занимает хранимый процесс, и сколько времени занимает код JDBC.
Конечно, я буду следовать рекомендациям MySQL по использованию CallableStatement, я уверен, что они сравнили это. Большинство приложений ничего не разделяют между Threads, и это редко бывает проблемой.

В большинстве драйверов JDBC используется только один сокет для каждого соединения. Я думаю, что MySQL также использует один сокет. Это идея плохой производительности для совместного использования одного соединения между несколькими потоками.

Если вы используете множественное соединение между разными потоками, вам требуется CallableStatment для каждого соединения. Для каждого соединения необходим пул CallabaleStatement. Простейшим для объединения в этом случае является объединение класса соединения и делегирование всех вызовов первому классу. Это можно очень быстро создать с помощью Eclipse. В завернутом методе prepareCall() вы можете добавить простой пул. Вам также нужен обернутый класс CallableStatement. Метод close возвращает CallableStatement в пул.

Но сначала вы должны проверить, действительно ли вызов дорог, потому что во многих драйверах уже есть такой опрос внутри. Создайте цикл prepareCall() и close() и подсчитайте время.

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

Когда вы готовитеCall, драйвер JDBC (может) сообщает системе РСУБД, что он выполняет большую работу, которая хранится на стороне сервера. Вы можете быть виновны в преждевременной оптимизации здесь.