A raiz não é específica o suficiente para dar uma sugestão firme, mas a lista completa do que pode ser feito é a seguinte:

• Cluster de banco de dados :Adequado para situações em que você não deseja alterar sua camada de aplicativo e banco de dados é tudo o que você toca. Há um limite de quanto você pode obter de um cluster de banco de dados. Se o volume de solicitações continuar crescendo, essa solução também falhará eventualmente. Mas a boa notícia é que você tem todas as funcionalidades que já tinha em um MySQL de instância única comum.
• Fragmentação :Como sua pergunta está marcada com MySQL e não suporta sharding por conta própria, se você quiser usar esta solução, precisará implementá-la em sua camada de aplicativo. Nesta solução, você distribuirá seus dados por vários bancos de dados (de preferência em várias instâncias do MySQL em hardware separado) logicamente. Será sua responsabilidade encontrar o banco de dados apropriado que contém seus dados designados. É uma das soluções mais eficazes de sempre, mas nem sempre é viável. Sua maior falha é que os dados espalhados entre dois ou mais bancos de dados não podem ser incluídos em uma transação.
• Replicação :Dependendo do seu cenário, você pode incorporar a replicação de banco de dados e ter cópias de seus dados neles. Dessa forma, você pode se conectar a eles em vez do banco de dados mestre e reduzir a carga nele. A definição de replicação padrão é o cenário mestre/escravo no qual o fluxo de dados é unidirecional, do mestre para o escravo. Portanto, as alterações que você pode fazer no escravo enquanto forem aplicadas no salve, elas não afetarão o mestre. Mas também há uma configuração de replicação mestre/mestre na qual o fluxo de dados ocorre nos dois sentidos. No entanto, você não pode assumir a integridade atômica para alterações de dados simultâneas entre os dois mestres. No final, esta solução é mais eficaz se você planeja usá-la no modo mestre/escravo e usando escravos para acesso somente leitura.
• Cache :Talvez esta solução não deva ser incluída aqui, mas como seu tronco não a rejeita, aqui vai. Uma das maneiras de reduzir a carga do banco de dados é armazenar em cache seus dados depois de extraídos. Esta solução pode ser benéfica especialmente se a extração de dados for cara. Existem muitos servidores de cache por aí, como memcached ou redis . Dessa forma, você pode omitir muitas conexões de banco de dados, mas apenas para extração de dados.
• Outros mecanismos de armazenamento :você sempre pode mudar para mecanismos de melhor desempenho se o atual não fornecer o que você precisa. Claro que isso só é viável se suas necessidades permitirem. Hoje em dia existem mecanismos NoSQL, muito mais eficientes que RDBMS, que suportam sharding nativamente e você pode escalá-los linearmente com o mínimo de esforço. Também existem soluções baseadas em Lucene com recursos avançados de pesquisa de texto completo, fornecendo a mesma fragmentação automática. Na verdade, a única razão pela qual você deve usar um RDBMS tradicional é o comportamento atômico das transações. Mas se as transações não são obrigatórias, existem soluções muito melhores do que RDBMS.