一意の製品IDのリストを含むmysqlテーブル（table-A）があります。このテーブルを利用するアプリは、複数のスレッドを利用します。各スレッドはテーブルの行を選択し（最上位）、APIを使用して製品データを取得し、別のテーブルに更新します（テーブルB）。完了すると、スレッドはテーブルA内の対応する製品ID行を削除し、作業する別の行を選択します（テーブルBが更新されている間にテーブルAのすべての行が削除されるまでループします）。
アプリのスレッドがテーブルAの同じ行で誤って機能するのを防ぐにはどうすればよいですか？行が選択されないようにロックする方法はありますか？
例：アプリケーションのスレッド1は、テーブルAから行1を選択します。APIからすべての関連データをテーブルBに取得して更新するには、約10〜15秒かかります。これが発生している間、スレッド2が起動し、テーブルAをチェックして、作業する行を選択します。この場合、行1のみをロックして、スレッド2がそれを認識/読み取りせず、代わりに行2を選択するようにします。
ネイティブMySQLロックはこの機能を提供しません。列を使用して「ロック」を実行できます。
各スレッドに一意のIDがあるとするとthread_owner、デフォルトで0の名前の列を作成できます。
1つのスレッドは、次のような行を取得します。
UPDATE mytable
SET thread_owner = :my_threadID
WHERE thread_owner = 0
LIMIT 1
次に、次のように行を選択します（処理する行がない場合は、何も返されない可能性があります）。
SELECT *
FROM mytable
WHERE thread_owner = :my_threadID
次にそれを処理し、最後に削除します。
このソリューションは、MyISAMとInnoDBの両方で機能します。
ただし、InnoDBの場合、各UPDATEステートメントがthread_owner = 0のすべての行をロックしようとするため、処理が遅くなる可能性があります。また、毎回同じ順序ですべての行をロックしていることが確実でない限り、デッドロックが発生する可能性もあります。したがって、UPDATEステートメントでテーブル全体を明示的にロックしてみてください。
LOCK TABLES mytable WRITE;
UPDATE mytable
SET thread_owner = :my_threadID
WHERE thread_owner = 0
LIMIT 1;
UNLOCK TABLES;
そうすれば、MyISAMとInnoDBの両方が同じように機能します。
「テーブルのロック」コマンドを試してみてください。2つのウィンドウを使用して次のように表示しました。
jcho_1> lock table t1 write;
Query OK, 0 rows affected (0.00 sec)
jcho_2> select * from t1;
jcho_1がこれを行う場合、jcho_2はテーブルを解放して読み取ることができるようになるまで待機します。
jcho_1> unlock tables;
Query OK, 0 rows affected (0.00 sec)
jcho_2は彼のクエリで可能です。
jcho_2> select * from t1;
+----------+-------------+--------------+---------------------+
| actor_id | first_name | last_name | last_update |
+----------+-------------+--------------+---------------------+
| 206 | a | b | 0000-00-00 00:00:00 |
| 71 | ADAM | GRANT | 2006-02-15 04:34:33 |
| 132 | ADAM | HOPPER | 2006-02-15 04:34:33 |
...
| 0 | 0 | 0 | 0000-00-00 00:00:00 |
+----------+-------------+--------------+---------------------+
202 rows in set (1 min 27.67 sec)
