(Говорейки от гледна точка на MySQL...)
Някои „Правила на палеца“:
- Единичен
INSERT
:10 ms - 100 или повече реда, вмъкнати от един
INSERT
:10 пъти по-бързо на ред. BEGIN; INSERT...; INSERT...; ... COMMIT;
:Също 10 пъти.- Горното предполага HDD; SSD може да бъде още 10 пъти по-бърз.
- Ако всяка от няколко връзки прави вмъквания, те може да може да работи паралелно. 10 нишки може да са в състояние да свършат 5 пъти повече работа за едно и също изминало време. (Разбира се, това може добавят нежелана сложност към приложението.)
Подобни цифри за UPDATE
, въпреки че не е лесно да се правят различни актуализации на различни редове с една заявка.
Вашият тест показва 8,5 ms на ред UPDATEd
когато правите един ред наведнъж. Пакетиране с BEGIN...COMMIT
вероятно ще отнеме около 85 ms за всички 100 реда, дори и на HDD.
Някои приложения се поддават на групиране; някои не го правят. Ако искате да поговорим за подобряване на производителността на MySQL, трябва да навлезем в детайлите на вашето приложение.
Броячите „Харесвам“ и „Преглед“ може трябва да бъдат преместени в „паралелна“ таблица, тъй като те са склонни да се актуализират един по един, с известна намеса в друга дейност. Те също така са склонни автоматично да позволяват многонишковост, следователно много по-малко от 850ms на 100. При наистина висока активност (над, да речем, 1K показвания в секунда), такива броячи могат да бъдат изкуствено групирани чрез допълнителен код на приложение.
Моля, пренапишете вашия бенчмарк, за да отразите дейността, която ще се случи в реалното приложение. (Предполагам че актуализациите ще се извършват паралелно, а не последователно. И те ще бъдат разпределени произволно във времето.)
Друго нещо... Ако всеки „преброяване на прегледи“ идва на уеб сървър, тогава има и свързване и прекъсване на връзката; следователно изминало времето вероятно ще бъде повече от 8,5 ms. Но „изминалото“ не е критичният въпрос; истинският проблем е "колко актуализации могат да бъдат извършени в секунда".)
И още нещо... Ако тествате "паралелен", не удряйте един и същи ред с всяка заявка. Това вероятно ще бъде много по-бавно, отколкото ако ударите различни редове. (По-добре би било да уцелите произволен ред. Да имате отклонение в кой ред да уцелите би било още по-реалистично.)