Hebt u de cliënt op een afzonderlijke machine van de server gesplitst? Dat is een eerste, kleine stap in schaalvergroting.
Hebt u replicatie- en alleen-lezen-query's naar Slaves gestuurd? Dat kan onbeperkt lezen mogelijk maken schalen. (Maar dit gaat niet in op de UPDATE-vraag, behalve om de Master te verlichten.)
115 IOP's op een enkele, draaiende schijf zullen het vrijwel verzadigen. innodb_flush_log_at_trx_commit is standaard ingesteld op 1, wat leidt tot ten minste 1 IOP per transactie. Enkele tijdelijke oplossingen (totdat uw verkeer met nog eens 10x groeit)...
SSD's -- misschien 1000 IOP's.
Batch de updates (zoals vermeld door @N. B.) Dit vermindert het aantal "flushes" met 100x.
innodb_flush_log_at_trx_commit =2 -- om de flushes vrijwel te elimineren (met enig verlies van beveiliging).
Maar -- Zelfs als u de UPDATE's snel genoeg kunt doen, moet u dan niet ook de waarden lezen? Dat wil zeggen, er zal ruzie zijn. Hoeveel SELECT's op dezelfde tafel ben je aan het doen? 100/sec is misschien goed; 1000/sec kan zoveel interferentie veroorzaken dat het niet werkt.
Hoe groot is de tafel? Om dit te laten werken, moet het klein genoeg zijn om altijd in de cache te worden bewaard.
Reddit is een andere benadering - leg de updates daar vast. Trek vervolgens voortdurend de verzamelde tellingen uit en voer de benodigde UPDATEs uit.
Sharding -- Hier verdeelt u de gegevens over meerdere machines. Splitsen op een hash of lookup (of combinatie van de twee) van de userid is gebruikelijk. Vervolgens moet de UPDATE uitzoeken welke machine moet worden bijgewerkt en vervolgens de actie daar uitvoeren. Als je 10 shards (machines) hebt, kun je bijna 10 keer de updatesnelheid volhouden. Uiteindelijk is dit de enige manier waarop alle heavy hitters 100 miljoen gebruikers en miljarden zoekopdrachten per dag aankunnen.
PARTITIONEREN zal waarschijnlijk niet helpen. De code voor het opschonen van partities is nog niet efficiënt genoeg om te veel overhead voor zo'n kleine zoekopdracht te voorkomen.