O VisualVM conta um encadeamento como usando o tempo de CPU sempre que a JVM pensa que é executável. Isso significa que qualquer thread que não esteja aguardando um bloqueio é considerado executável, mais ou menos, incluindo threads esperando por E/S no kernel! É aqui que a grande quantidade de uso da CPU em com.myql.jdbc.utils.ReadAheadInputStream.fill() está vindo. Então, em vez de um problema de CPU, você tem um problema de E/S.

Há algumas coisas que você pode fazer no lado da JVM, mas não muito simples de otimização:

1. Ajuste o tamanho do pool de conexões. 1.000 consultas simultâneas é muito muito . A menos que sua instância MySQL seja realmente massiva, ela terá problemas para lidar com esse nível de carga e consumirá muito tempo apenas alternando entre as consultas. Tente diminuir o tamanho do pool para 250 ou até 50 e faça um benchmark nele.
2. Faça menos ou menores consultas. Se seu aplicativo for pequeno, pode ser trivialmente óbvio que cada linha de cada consulta é necessária, mas talvez seu aplicativo seja maior que isso. Os diferentes locais que consultam os mesmos dados ou duas consultas diferentes podem ser combinadas em uma que satisfaça a ambos?