(At tale fra et MySQL-synspunkt...)
Nogle "tommelfingerregler":
- Enkelt
INSERT:10 ms - 100 eller flere rækker indsat af en enkelt
INSERT:10 gange så hurtigt pr. række. BEGIN; INSERT...; INSERT...; ... COMMIT;:Også 10x.- Ovenstående forudsætter HDD; SSD er muligvis yderligere 10 gange hurtigere.
- Hvis flere forbindelser hver især laver indsættelser, kan de kunne køre parallelt. 10 tråde kan måske udføre 5 gange arbejdet på samme forløbne tid. (Dette kan selvfølgelig tilføje uønsket kompleksitet til appen.)
Lignende tal for UPDATE , selvom det ikke er let at lave forskellige opdateringer på forskellige rækker med en enkelt forespørgsel.
Din test viser 8,5 ms pr. række UPDATEd når du laver en række ad gangen. Batching enten med BEGIN...COMMIT vil sandsynligvis tage omkring 85ms for alle 100 rækker, selv på HDD.
Nogle applikationer egner sig til batching; nogle gør ikke. Hvis du vil tale om at forbedre MySQL-ydeevnen, skal vi komme ind på detaljerne i din ansøgning.
"Synes godt om" og "Vis"-tællere kan skal flyttes til en 'parallel' tabel, da de har tendens til at blive opdateret én ad gangen, med en vis forstyrrelse af anden aktivitet. De har også en tendens til automatisk at tillade multi-threading, og dermed meget mindre end 850 ms pr. 100. I virkelig høj aktivitet (over f.eks. 1K visninger pr. sekund) kan sådanne tællere samles kunstigt via ekstra app-kode.
Omskriv venligst dit benchmark for at afspejle den aktivitet, der vil ske i den rigtige applikation. (Jeg gætter at opdateringerne vil ske parallelt, ikke serielle. Og de vil blive spredt ud tilfældigt over tid.)
En anden ting... Hvis hvert "view count" kommer til en webserver, så er der også til- og frakobling; derfor forløbet tiden er sandsynligvis mere end 8,5 ms. Men "forløbet" er ikke det kritiske spørgsmål; det virkelige problem er "hvor mange opdateringer kan udføres pr. sekund".)
Og en anden ting... Hvis du tester 'parallel', skal du ikke ramme den samme række ved hver anmodning. Det vil sandsynligvis være meget langsommere, end hvis du rammer forskellige rækker. (Det ville være bedre at ramme en tilfældig række. At have en skævhed i, hvilken række der skal rammes, ville være endnu mere realistisk.)