1 回のトランザクションで 1 ～ 3 個のテーブルを更新する 35 個の関数があります。ただし、更新を実行するだけでなく、クエリも実行します。
- 表 1 は、行更新のみのアクションといくつかの照会を行います。
- 表 2 は、既存の行に対してクエリと行レベルの更新を行い、場合によっては行を削除および追加します。表 2 には、行の削除、挿入、または更新の前後に、トランザクション内にクエリがある場合があります。
- 表 3 は、上記の表 2 のアクションの結果に基づいて行の更新を行います。
私の最初のアクションは、最後にテーブル 3 の更新がすべて完了していることを確認することです。
表 1 は他の 2 つの表から独立しており、おそらく最初または最後になる可能性があります。したがって、表 2 は表 3 が変更される前に来る必要があります。
私の最初の懸念は、表 2 のアクションでは、クエリを実行してから更新を行い、さらにクエリを実行し、さらに更新を実行する場合があることです。これを行わないようにコードを再編成する必要がありますか。
私の 2 番目の懸念は、テーブル 3 が、サーブレット スレッドで高速でなければならないテーブルであるということです。表 3 は、単独で単純に照会するために使用されます。しかし、行レベルのロックがこれらのクエリを停止するようです。
必要に応じて、上記のテーブル セット メンテナンス コードを、1 つのスレッドから 1 つのクラスター全体のプロセスに入れることができます。更新速度は問題ありません。ただ、テーブル 3 に対するクエリは高速です。そして、デッドロックが発生することはありません。
Oracle と Innodb の違いがわからないので、そこで質問があります。(後で Oracle にアップグレードする予定です。)
基本的に、私は何に注意すべきかについての指針を探しています。もちろん、各 updater 関数の開始時にテーブル 2 とテーブル 3 の完全なテーブル ロックを強制することもできますが、そうすると Table3 サーブレット クエリ スレッドが影響を受けます。だから、それは解決策のようには見えません。
また、テーブル 2 自体に関連して、一部の関数がクエリを実行し、クエリに基づいて更新し、更新に基づいて新しいクエリを実行し、結果をテーブル 3 に更新するなど、さらに多くの更新を行うことを心配しています。本当に厄介です。
おすすめは？アンディ
2 つのテーブルの同じ行が同時に更新される可能性があるため、テーブルを同じ順序で更新するように注意しました。テーブルの 1 つに 2 つのインデックスがあり、インデックスを更新するにはテーブル ロックが必要なようです。一部の関数は、繰り返しループで、テーブル 1 をクエリし、テーブル 1 を更新し、オプションでテーブル 2 をクエリし、テーブル 2 を更新します。このテーブルは、すべてのコンテンツのツリーにすべての親子関係を保持するため、すべてのユーザーにわたって大量の更新が行われます。