0

これを実装する方法に関する推奨事項はありますか?

table1 は常にINSERT編集されます。これには、 table2 のすべての行UPDATEを各 table1 で d する必要がありますINSERT。また、MySQL が (PHP の計算速度と比較して) 最も効果的かどうかはわかりませんが、table2 の各行にもアルゴリズムを適用する必要があります。

ユーザーがINSERT.

したがって、私の問題は、で合計テーブルを使用すると、UPDATE大量のロックが発生することです (または、そのキーの一部がdになるため、テーブル全体を複合主キーで ing するTRIGGERときの InnoDB のロックから理解できます)。UPDATUPDATE

INSERT現在、cron ジョブを使用することを考えていますが、スケジュールではなく table1のユーザーに対して実行したいと考えています。

だから私は多分考えていたCURSOR...

table2で最速かつ「絶対に」ロックしない方法は何ですか?

よろしくお願いします！

テーブル構造

table2 はすべてINT速度の s です。ただし、2 列の主キーがあります。それらの列の 1 つはUPDATEd の内容です。そのキーは、同様に重要なラピッドSELECTs 用です。

table1 の平均行数は、table2 の行数の約 2.5 倍です。

table2 は実際には非常に小さく、約 200 MB です。

4

1 に答える 1

2

まず第一に、あなたがしようとしていることはほとんど不可能です.「絶対にロックしない」ことで、 INSERTsをあるテーブルに別のテーブルにエスカレートできるRDBMSについては知りません。UPDATE

それは言った：

  • 私の最初の調査ポイントは、このホットスポットを最適化するためにスキーマをオーバーホールできるかどうかです。
  • これが達成できない場合は、table2既存のデータから再作成できるインメモリ型の作成を検討することをお勧めします ( table1DB の再起動が必要な場合は、そのスナップショットを最大 PK と共に保持し、ロール フォワードするなど)。毎回すべての行を更新する必要があるため、非常に大きくINSERTするtable1ことはできません。
  • 調査の次のポイントは、挿入ロジックによって呼び出されるストアド プロシージャに とINSERTを配置することです。UPDATEこれにより、キャッチアップ時にロック地獄が発生する可能性がはるかに低くなり、暴走状態になります。
于 2013-01-06T18:31:03.093 に答える