(Sprekend vanuit een MySQL-oogpunt...)
Enkele vuistregels:
- Enkele
INSERT:10ms - 100 of meer rijen ingevoegd door een enkele
INSERT:10 keer zo snel per rij. BEGIN; INSERT...; INSERT...; ... COMMIT;:Ook 10x.- Het bovenstaande gaat uit van HDD; SSD is misschien nog eens 10x sneller.
- Als meerdere connecties elk inserts doen, mogelijk parallel kunnen lopen. 10 threads kunnen misschien 5 keer het werk doen in dezelfde verstreken tijd. (Natuurlijk, dit mag voeg ongewenste complexiteit toe aan de app.)
Vergelijkbare cijfers voor UPDATE , hoewel het niet eenvoudig is om verschillende updates op verschillende rijen uit te voeren met een enkele zoekopdracht.
Uw test toont 8,5 ms per rij UPDATEd wanneer u één rij tegelijk doet. Batching ofwel met BEGIN...COMMIT zal waarschijnlijk ongeveer 85 ms duren voor alle 100 rijen, zelfs op HDD.
Sommige toepassingen lenen zich voor batching; sommigen niet. Als u wilt praten over het verbeteren van de MySQL-prestaties, moeten we ingaan op de details van uw toepassing.
Tellers "Vind ik leuk" en "Bekijken" kunnen moeten worden verplaatst naar een 'parallelle' tabel, omdat ze de neiging hebben om één voor één te worden bijgewerkt, met enige interferentie met andere activiteiten. Ze hebben ook de neiging om automatisch multi-threading toe te staan, dus veel minder dan 850 ms per 100. Bij echt hoge activiteit (meer dan bijvoorbeeld 1K views per seconde), kunnen dergelijke tellers kunstmatig worden gegroepeerd via extra app-code.
Herschrijf uw benchmark om de activiteit weer te geven die in de echte toepassing zal plaatsvinden. (Ik vermoed dat de Updates parallel zullen plaatsvinden, niet serieel. En ze zullen willekeurig over de tijd worden verspreid.)
Nog iets... Als elke "view count" naar een webserver komt, dan is er ook connect en disconnect; vandaar de verstreken tijd is waarschijnlijk meer dan 8,5 ms. Maar "verstreken" is niet het kritieke punt; het echte probleem is "hoeveel updates kunnen er per seconde worden uitgevoerd".)
En nog iets... Als je 'parallel' test, raak dan niet bij elk verzoek dezelfde rij. Dat zal waarschijnlijk veel langzamer zijn dan wanneer je verschillende rijen raakt. (Een willekeurige rij raken zou beter zijn. Een voorkeur hebben in welke rij te raken zou nog realistischer zijn.)