O local canônico para as informações de desempenho do MySQL é blog de desempenho do MySQL . Existe também o livro High Performance MySQL de Jeremy Zawodny.
Você pode querer examinar alguma forma de pool de conexões em seu aplicativo, em que ele reutilizará as conexões de banco de dados existentes, em vez de criar uma nova conexão para cada nova sessão. Isso reduzirá a sobrecarga de abrir uma nova conexão TCP e qualquer processamento que o MySQL faça. Ele também deve reduzir o número de conexões ociosas que o MySQL está executando, já que cada conexão requer uma certa quantidade de memória para existir.
Outra coisa que você pode fazer para reduzir massivamente a carga em seu banco de dados é integrar memcached. Memcached é um armazenamento de valor de chave distribuído na memória; como um mapa hash anexado à rede. Você modificaria seu aplicativo para pesquisar no memcached e, se não houvesse dados, para verificar o banco de dados. Quando você altera os dados, você os grava no banco de dados e invalida os dados no memcached. Isso significa que você estaria pesquisando o memcached significativamente mais rápido em vez do MySQL.
Uma vez que você tenha implementado esses recursos, e somente quando tiver, você pode começar a procurar ajustes nos parâmetros do MySQL. Há um enorme potencial para estragar as coisas e acabar com um banco de dados que acaba mais lento do que era antes, se você não sabe o que está fazendo. Eu teria pelo menos lido o livro MySQL Performance antes de tentar isso.
Se você puder gastar mais dinheiro, a primeira melhoria seria dividir seu banco de dados em um servidor separado. Se isso não for suficiente, você pode começar a usar uma configuração de replicação mestre e escrava, onde as gravações vão para o servidor mestre, mas as leituras são distribuídas entre o mestre e o escravo. Isso funciona particularmente bem para cargas de trabalho de leitura pesada, o que é bastante comum.