（MySQLの観点から言えば...）
いくつかの「経験則」：
- 単一の
INSERT：10ms - 1つの
INSERTによって挿入された100行以上 ：1行あたり10倍の速さ。 -
BEGIN; INSERT...; INSERT...; ... COMMIT;：また10倍。 - 上記はHDDを想定しています。 SSDはさらに10倍高速になる可能性があります。
- 複数の接続がそれぞれ挿入を行っている場合、それらは可能性があります 並行して実行することができます。 10スレッドは、同じ経過時間で5倍の作業を実行できる可能性があります。 （もちろん、これはかもしれません アプリに不要な複雑さを追加します。）
UPDATEの同様の数値 、ただし、1つのクエリでさまざまな行に対してさまざまな更新を行うのは簡単ではありません。
テストでは、1行あたり8.5ミリ秒のUPDATEdが示されています 一度に1行ずつ実行する場合。 BEGIN...COMMITのいずれかを使用してバッチ処理する HDDでも、100行すべてで約85msかかるでしょう。
一部のアプリケーションはバッチ処理に適しています。しないものもあります。 MySQLのパフォーマンスの向上について話したい場合は、アプリケーションの詳細を調べる必要があります。
「いいね」と「表示」のカウンター 一度に1つずつ更新される傾向があり、他のアクティビティに干渉する傾向があるため、「並列」テーブルに移動する必要があります。また、マルチスレッドを自動的に許可する傾向があるため、100あたり850ミリ秒未満です。非常に高いアクティビティ（たとえば、1秒あたり1Kビュー以上）では、このようなカウンターは追加のアプリコードを介して人為的にバッチ処理できます。
実際のアプリケーションで発生するアクティビティを反映するようにベンチマークを書き直してください。 （私は推測 更新はシリアルではなくパラレルで行われます。そして、それらは時間全体にランダムに分散されます。）
別のこと...各「ビューカウント」がWebサーバーに到達した場合、接続と切断もあります。したがって、経過 時間は8.5ms以上になる可能性があります。しかし、「経過」は重大な問題ではありません。本当の問題は「1秒間に実行できる更新の数」です。）
そして別のこと...「並列」をテストする場合は、各リクエストで同じ行をヒットしないでください。別の行をヒットする場合よりも、おそらくはるかに遅くなります。 （ランダムな行をヒットする方が良いでしょう。ヒットする行にバイアスをかけることはさらに現実的です。）