Você dividiu o cliente em uma máquina separada do servidor? Esse é um primeiro passo menor na escala.

Você tem consultas de replicação e somente leitura enviadas para Slaves? Isso pode permitir leitura ilimitada dimensionamento. (Mas isso não aborda a questão UPDATE, além de aliviar a carga no Master.)

115 IOPs em um único disco giratório praticamente o saturarão. O padrão innodb_flush_log_at_trx_commit é 1, o que leva a pelo menos 1 IOP por transação. Algumas soluções temporárias (até que seu tráfego cresça mais 10x)...

SSDs -- talvez 1000 IOPs.

Agrupe as atualizações (como mencionado por @N.B.) Isso reduz em 100x o número de "flushes".

innodb_flush_log_at_trx_commit =2 -- para eliminar virtualmente os flushes (com alguma perda de segurança).

Mas -- Mesmo que você possa fazer os UPDATEs rápido o suficiente, você também não precisa ler os valores? Ou seja, haverá disputa. Quantos SELECTs no mesmo mesa você está fazendo? 100/s pode estar ok; 1000/seg pode causar tanta interferência que não funcionará.

Qual o tamanho da mesa? Para que isso funcione, ele precisa ser pequeno o suficiente para ser armazenado em cache o tempo todo.

O Reddit é outra abordagem - capture as atualizações lá. Em seguida, retire continuamente as contagens acumuladas e faça as ATUALIZAÇÕES necessárias.

Sharding -- É aqui que você divide os dados em várias máquinas. A divisão em um hash ou pesquisa (ou combinação dos dois) do ID do usuário é comum. Em seguida, o UPDATE precisa descobrir qual máquina atualizar e executar a ação lá. Se você tiver 10 shards (máquinas), poderá sustentar quase 10 vezes a taxa de atualização. Em última análise, esta é a única maneira que todos os pesos pesados ​​podem lidar com mais de 100 milhões de usuários e bilhões de consultas/dia.

PARTICIONAR provavelmente não ajudará. O código de remoção de partição ainda não é eficiente o suficiente para evitar muita sobrecarga para uma consulta tão pequena.