2017-04-17 9 views
0

皆さんも知っているように、Row(レコード)ロックはInnodbエンジンでサポートされています。 次のsqlがアトミックでありトランザクションであることは間違いありません。は処理中にすべてのテーブルをロックするmysql

update tableA t 
set t.oneField = someValue 
where t.primaryKey = id 

しかし、私は次のような状況で混乱しています(なしWHERE条件

update tableA t 
set t.oneField = someValue 

私は、このSQLを実行しながら、テーブル全体をロックするのmysqlますされてお聞きしたいですか? 具体的には、rowAが処理され、mysqlが他の行を処理しているときに、このSQLがまだ処理中にrowAがロックされています? rowBがロックされているかどうかを知るために、ツールまたはSQLコマンドを使用できますか?

私は文書https://dev.mysql.com/doc/refman/5.5/en/innodb-locking.htmlを読んだことがありますが、まだ混乱しています。

可能であれば、私にあなたの結論を説明するための具体的なケースやデモや実験を教えてください。何か私は自分自身でそれを行うことができる何もOK。

ありがとうございます。

+0

どうすれば更新テーブルA がt.oneField = someValueに設定されます。ここで、t.primaryKey in(1,2、......) – jingb

答えて

0

「テーブルをロックしていない」と言っているのはです。技術的にはです。実際には、「すべての行をロックします」。ユーザーにはこれらは同じように感じます。

2つのクエリの両方が実行しようとしますが、すぐにお互いに干渉します。 おそらく他は終了するまで遅れるでしょう。 の状況では、「デッドロック」が検出され、1つのクエリが中止されます。 (エラーをテストする必要があります)

前任者(ENGINE=MyISAM)との重要な違いは、すべての操作が「テーブルをロックしました」ということです。別の行を更新していた別のスレッドが終了するまで、ある行の更新を開始できませんでした。そして、UPDATESELECTの干渉が大きかった。

InnoDBでは、別々の行の更新が同時に発生する可能性があり、更新が行われている間に選択を続行することもできます。

+0

** InnoDBでは、別々の行の更新が同時に起こる可能性があります。更新が行われている間に**続行します。だから、innodbは、SQLがまだ実行されている間にSQLが処理している行をロックしないことを意味します。 – jingb

+0

@jingb - はい、それは良い要約です。しかし、「まったく、積極的に、100%」と躊躇しています。なぜなら、まれな、歪みのある、あいまいなエッジケースがあるため、やや異なることが起こるからです。したがって、エラーをチェックしてください。 InnoDBは物事を「楽観的に」実行します - 競合はまれです。 InnoDBはそれらのほとんどを透過的に処理できます。 1つのスレッドを遅延させることで固定されます(やはり透過的に)。デッドロックが発生することがあります。 –

関連する問題