MySQLアップデートステートメントが高価ですか？

Question

スケーラブルなMySQLスキーマを書く方法について私はできる限り多くのことを読んできましたが、これが良い考えかどうかはまだ分かりません。

私はこのプロジェクトをRDSでEC2にホストしています。

私のデータベースでは、私は推測すると約70％の書き込みと30％の読み込みより多くの書き込みになるコアテーブルを持っています。

ただし、テーブルに新しい行を作成すると、5秒ごとに更新を追加する必要があります。全体として、複数の行が毎秒追加/更新されるので、を意味し、UPDATE文は1秒ごとに実行されます。。

私が読んできたことに基づいて、MySQLにはテーブルに書き込むときに起こるテーブルロックと呼ばれるものがあります。このテーブルもかなり読み込まれているので、行にUPDATE文を使用するにはあまりにも多くのオーバーヘッド/ロックが発生しますか？

（私の知る限りでは）私のオプションは次のとおりです。頻繁に大きなテーブルの上に

1. 実行（Do）UPDATE文（毎秒または多分それ以上）
2. 私は行を作成するステージング表を持っていますそれらを更新し、準備ができたら（行がファイナライズされるまで約20分）、行をステージングテーブルからメインテーブルに発送します。

私はそれは、彼らがコンテンツを見ることができる前に、私のユーザーは約20分待ってますので、ステージング表を避けたいが、それは必要悪だかない場合、私は思ったんだけど。

他のアイデアはありますか？提案？

ありがとうございました！

Answer 1

テーブルロックを適用するかどうかは、ストレージエンジンによって異なります。 MyISAMはテーブルロックを行い、InnoDBは行ロックを行います。

あなたはと書き込み行を読みたいと、あなたはInnoDBはそれが（作家が読者をブロックしない、読者は作家をブロックしない）の各行への同時アクセスを許可しますで使用する必要があります

の場合あなたは主キーに基づいて行をudpate、彼らはかなり高速でなければなりません（あなたのサーバーがこれによって生成されるbeeingに追いつくことができる場合）。

Answer 2

Updateステートメントが高価であるかどうかにかかわらず、とにかくそれを行う必要があるように見えます。テーブルを更新しないという選択肢があれば、それはより効果的なものになるはずですが、そうではないと思います。

あなたが求めているような真の質問は、パフォーマンスよりも並行性があるようです。具体的には、小規模な更新が多数ある場合の並行性が向上するか、変更の合計数が同じであるバッチ更新が少なくなるかを問われているようです。

私の経験では、並行処理のためにバッチ処理するのではなく、たくさんの小さな更新を行うほうがはるかに優れています。ただし、バッチ処理を行うと、一般的にパフォーマンスが向上します（更新の場合）。

もう1つのことは、複数のタイプのロックがあることです。更新と選択のためのテーブルのロックは同じではなく、ステートメントが行、ページ、またはテーブル全体をロックするかどうかも考慮する必要があります。通常、ロックはかなりローカライズされていますが、このタイプのアプリケーションでは、ロック戦略の具体的な内容と、特定のニーズに合わせて操作する方法をお読みください。