la forma correcta es 'no hacer' conexiones mysql, intentar que todas las consultas esten cacheadas y 'serializadas' en disco, con un timeout de 10 minutos, por ejemplo. la forma mas o menos correcta de hacer esto es hacer un MD5 a la query mysql, y cachear el resultado serializado en disco con dicho numero MD5 como nombre de archivo. cuando tengas otra consulta, haces el MD5 y mira si existe dicho fichero en disco y si no ha pasado el timeout, en tal caso, deserializa y para adentro.
si eres mas puntilloso, programate una capa ORM (no es nada complicado, es una clase por tabla, y puedes extender gran parte de la funcionalidad de una a otra) que cumpla el interfaz CRUD, y que en caso de querys basadas en PK (primary key) haga la cache en disco 'serializado'. puesto que todo acceso a la BBDD se hace a traves de ORM, puedes detectar cuando se realiza una escritura a Mysql, y hacer 'shadow write', o sea, escribir al MYSQL y serializar a disco a la vez.
y ya, para el colmo de la velocidad, busca informacion sobre handlersocket, PERO OJO, solo para lecturas de la BBDD, la escritura en la BBDD a traves de handlersocket no invalida la cache y puedes obtener datos erroneos en posteriores lecturas.
el resto de la gente te dira que uses memcached. mi opinion es que no la uses, ya que con este sistema de cache de disco, puedes 'confiar' en que la cache de disco de linux haga su trabajo y mantenga en memoria los registros serializados que mas se usen.
la ultima alternativa es olvidarte de mysql y usar mongodb, que puede multiplicar facilmente por 5 tu rendimiento actual de mysql.
).