Hai diviso il client in una macchina separata dal server? Questo è un primo, minore, passaggio nel ridimensionamento.
Hai query di replica e di sola lettura inviate a Slaves? Ciò può consentire una lettura illimitata ridimensionamento. (Ma questo non risolve la domanda di AGGIORNAMENTO, se non per alleggerire il carico sul Master.)
115 IOP su un singolo disco rotante lo satureranno praticamente. innodb_flush_log_at_trx_commit il valore predefinito è 1, che porta ad almeno 1 IOP per transazione. Alcune soluzioni temporanee (fino a quando il tuo traffico non cresce di altre 10 volte)...
SSD -- forse 1000 IOP.
Batch gli aggiornamenti (come menzionato da @N.B.) Questo riduce di 100 volte il numero di "flush".
innodb_flush_log_at_trx_commit =2 -- per eliminare virtualmente i flush (con una certa perdita di sicurezza).
Ma -- Anche se puoi eseguire gli AGGIORNAMENTI abbastanza velocemente, non hai bisogno anche di leggere i valori? Cioè, ci sarà contesa. Quanti SELECT sullo stesso tavolo stai facendo? 100/sec potrebbe andare bene; 1000/sec potrebbe causare così tante interferenze da non funzionare.
Quanto è grande il tavolo? Affinché tutto ciò funzioni, deve essere abbastanza piccolo da poter essere sempre memorizzato nella cache.
Reddit è un altro approccio:acquisisci gli aggiornamenti lì. Quindi estrai continuamente i conteggi accumulati ed esegui gli AGGIORNAMENTI necessari.
Sharding:è qui che dividi i dati su più macchine. La divisione su un hash o una ricerca (o una combinazione dei due) dell'id utente è comune. Quindi l'AGGIORNAMENTO deve capire quale macchina aggiornare, quindi eseguire l'azione lì. Se hai 10 frammenti (macchine), puoi sostenere quasi 10 volte la velocità di aggiornamento. In definitiva, questo è l'unico modo in cui tutti i più potenti possono gestire oltre 100 milioni di utenti e miliardi di query al giorno.
È probabile che la partizione non sia di aiuto. Il codice di eliminazione della partizione non è ancora abbastanza efficiente da evitare un sovraccarico eccessivo per una query così piccola.