問題タブ [rowlocking]

行ロックを使用して、実行中に特定の行が更新されないようにしようとしていますが、これを実行している間はテーブルをまったく使用できないという問題があります。

このトランザクションの実行中に両方のテーブルに対して挿入を実行し、両方がコミットされるのを待ちました。読み取りと削除のために特定の行をロックし、テーブルを使用できるようにするにはどうすればよいですか?

レコードの場合、select は数万のレコードを生成します。テーブルにはクラスター化された主キーがあり、ステータス列にはインデックスがあります。

私はテーブルを持っています...

つまり...ファクターId1の場合、1500レコードがあります...そしてファクターId 2の場合、同じ数のレコードがあります。

ファクターID1および2の場合、「ファクター値」を除いてすべての値は同じです。

上記のテーブルを他のテーブルと結合してデータをフェッチすると...FactorID1ですぐに結果が得られます...しかし、「2」をクエリすると...実行が終了することはありません。

これは私には奇妙な誤りのようです。行ロックに関連するものですか？私を助けてください。

以下のストアド プロシージャを使用して、DB から利用可能なログイン情報をランダムに選択しています。しかし、複数のスレッドが利用可能なログイン情報を取得しようとすると、レコードのタイムスタンプ フィールドを更新しているにもかかわらず、重複したレコードが返されます。

ここで行をロックして、一度返されたレコードが再び返されないようにするにはどうすればよいですか?

パッティング

WITH (ホールドロック、ローロック)

役に立たなかった！

... ... ...

次の構造のクエリがあります。

これは、InnoDBテーブルに対する単一テーブルのSELECTステートメントです。フィールドposition（INT NOT NULL）にはインデックスがあります。ステータスはENUMであり、インデックスも付けられます。

SELECT ... FOR UPDATEマニュアルページには、読み取ったすべての行がロックされると書かれています。この場合、1つの行だけがロックされることを正しく理解していますか？というか、テーブル全体をロックしますか？

EXPLAINどの行がクエリでロックされるかを決定することは可能ですか？はいの場合-どのように？空のテーブルに対するクエリの説明は、次のことを示しています。

この質問は、これの論理的な続きです。

SELECT ... ORDER BY xxx LIMIT 1 FOR UPDATEによってロックされる行数はいくつですか？

私がそのようなSELECTを持っているとしましょう：

idは主キーで、ステータスはインデックスに登録されます。

この場合のMySQLロック戦略は何ですか？

1. 両方の条件にのみ一致する行をロックする
2. 最初の条件に一致するすべての行をロックし、2番目の条件に一致するすべての行を個別にロックします
3. テーブル全体をロックする

最も論理的なのは2だと思います。しかし...わかりません。詳細を教えていただけますか？

このマルチアップデートクエリがある場合

user テーブルの行 10 には既に「same_name_i_already_had」という名前が付けられているため、更新しないでください。

一方、user_profile テーブルの行は年齢が異なるため、MySQL はそれを更新する必要があります。MySQLを RDBMS として、行レベルのロック システムを両方のテーブルのエンジンとして使用するInnoDB

を 想定すると、MySQL はその行の名前フィールドを更新する必要がないにもかかわらず、ユーザー テーブルの行をロックしますか?

ここで簡単な質問/説明が必要です。レコードが同時に更新される可能性が非常に高い DB テーブルがあります。私はアプリケーションに Zend Framework を使用しています。これを回避するための 2 つの方向性について読みました。それが最善の解決策です。2 番目はトランザクションです: $db->beginTransaction(); ... $db->commit();

ここで、InnoDB などのトランザクション ストレージ エンジンを使用していると仮定すると、トランザクションがより一般的なソリューションのように思えます。ただし、次のシナリオは回避できますか。

ユーザー A が Web ページ上にいる -> データを送信する -> トランザクションを開始する -> 行を読み取る -> 新しい値を計算する -> 行を更新する -> 保存する -> コミットする

ユーザー B は同時に同じ Web ページにいて、同時にデータを送信します。ここでは、ほぼ同時であるとしましょう (ユーザー B は、ユーザー A のトランザクションのトランザクションの開始とコミットの間の時点で更新関数を呼び出します)。レコードを更新するための正確な計算を達成する前に、ユーザー A のトランザクションからコミットされたデータに対して。

いいえ:

データベース行の開始値: 5 ユーザー A が値 5 を送信します。 (トランザクションの開始 -> 値 (5) の読み取り -> 送信された値の追加 (5+5=10) -> 更新された値の書き込み -> 保存 -> コミット)

ユーザー B は値 7 を送信します。ユーザー B のトランザクション読み取り値が 5 ではなく 10 であることを確認する必要があります (読み取り前に更新が行われていない場合)。

これは長々とした説明であることは承知しています。申し訳ありませんが、質問を単純化するための正しい用語が正確にはわかりません。

ありがとう

SQL Server Management Studio でテーブルを右クリックして [上位 200 行の編集] を選択すると、表示しているデータがロックされるのはどの時点ですか?

私の同僚は、この方法でデータを表示すると、データ行をロックできると述べました (行にカーソルを置いてデータの編集を開始すると彼が言ったときだと思います)。

このコンテキストでデータをロックできるのはこれだけですか?

私は現在、pgTapを使用して、かなり大量のPostgreSQLストアドプロシージャに単体テストを追加しています。

一部のプロシージャは、行を明示的にロックする操作を実行します。これらのロックは、アプリケーションにとって重要です。

ロックする必要のある行がロックされていることと、ロックされるべきではない行がロックされていないことを確認するテストを作成するにはどうすればよいですか？

私が現時点で持っている唯一の「手がかり」はpgrowlocks拡張機能です。これにより、トランザクションは別のトランザクションによってロックされた行をチェックできます。ただし、現在のトランザクションには独自のロックがないように見えるため、2つのトランザクションを同期するために何かを使用する必要があります。かなり間違えない限り、pgTapを使用してそれを行う方法はありません。

（注：PostgreSQL 9.1を使用）

私のDBスキーマはJob->（Many）JobData->（Many）Resultsです。ジョブは複数のJobData行に分割されるため、複数のスレッドがジョブの「チャンク」（各JobData行）を処理できます。次に、処理スレッドは、処理するJobData行ごとに結果行を挿入します。

単一のスレッドは、すべての結果が読み取られるまで、ループで結果を読み取ろうとします。 同時に、スレッドはJobData行を処理し（すべてが処理されるまで）、結果を挿入できることに注意してください。 したがって、ループでは、このSPへの各呼び出しはJobKeyを渡します...しかし、どういうわけかこのコードを使用すると、結果は複数回読み取られます（非常に低い頻度...つまり、結果の8000行あたり3行未満）が、ランダムにしか再現できません。

UPDLOCKに関するUPDATETOPステートメントの横のコードに以下のコメントを追加しました。前もって感謝します。

編集：@gbnの回答に基づいて、私が今持っているものを配置したかっただけです。SP全体を除外しますが、UPDATEステートメントは次のようにフォーマットされます。

数日間正常に実行されているので、うまくいけば問題を解決しました。これがテーブルヒントの適切な使用に見えない場合は、遠慮なくお知らせください。