MySQLがInnoDBテーブルを更新するときにexaclyの行をロックすると、

Question

私はこのmultiupdateクエリを持っている場合は

UPDATE user u 
INNER JOIN user_profile up ON up.user_id = u.id 
SET u.name = 'same_name_i_already_had', up.profile.age = 25 
WHERE u.id = 10 

のは、ユーザーテーブルの行10は、すでに「same_name_i_already_had」の名前を持っているので、それが更新されてはならないとしましょう。

一方、user_profileテーブルの行の年齢が異なるため、MySQLはそれを更新する必要があります。

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

、両方のテーブルのエンジンとしての行レベルのロッキングシステムとRDBMSとInnoDBのとしてのMySQLを仮定？

ありがとうございます！

Answer 1

userに行をロックします。優れたinnotopツールを使用してこれを確認できます。

• innotopを実行し、 'L'キーを押すと、InnoDBロックの画面が表示されます。
• 別のセッションを開き、MySQLにログオンして、START TRANSACTIONにログインします。
• 示されたUPDATEを実行しますが、COMMITはまだ実行していません。
• innotop画面でロックを表示します。

たとえば、MySQL 5.5を実行しているテストVMにuserとuser_profileというテーブルを作成し、上記の手順を実行しました。出力は次のとおりです。

[RO] Locks (? for help) localhost, 08:34.568, InnoDB 10s :-), 0.10 QPS, 2/0/0 con/run/cac thds, 5.5. 

__________________________________________ InnoDB Locks __________________________________________ 
ID Type Waiting Wait Active Mode DB Table   Index Ins Intent Special   
2 TABLE   0 00:00 02:35 IX test user       0     
2 RECORD  0 00:00 02:35 X  test user   PRIMARY   0 rec but not gap 
2 TABLE   0 00:00 02:35 IX test user_profile     0     
2 RECORD  0 00:00 02:35 X  test user_profile PRIMARY   0 rec but not gap 

Answer 2

ほぼ確実に、行に関係なくロックします。最初に変更を確認する簡単なフィールドはわかりません。ロック、書き込み、ロック解除する方が簡単で簡単です。ロックする前にチェックがあった場合は、競合状態があります。ロックが完全に回避するものです。