面接では選択式で聞かれましたが......。.for updateはテーブルをロックするか、行をロックするか？

select query文はロックを追加しませんが、select ......for updateはクエリであることに加えてロックされ、悲観的なロックとなります。

つまり、インデックス/プライマリキーを使用するかどうかによって、行ロックとテーブルロックのどちらが追加されるのでしょうか。

インデックス/プライマリーキーを使用しない場合はテーブルロック、そうでない場合は行ロックです。

バリデーション

ビルドテーブルsql

//id is the primary key  
//name is a unique index
CREATE TABLE `user` (
	`id` INT ( 11 ) NOT NULL AUTO_INCREMENT,
	`name` VARCHAR ( 255 ) DEFAULT NULL,
	`age` INT ( 11 ) DEFAULT NULL,
    `code` VARCHAR ( 255 ) DEFAULT NULL,
	PRIMARY KEY ( `id` ),
    KEY `idx_age` ( `age` ) USING BTREE 
) ENGINE = INNODB AUTO_INCREMENT = 1570068 DEFAULT CHARSET = utf8

手動コミットには @@autocommit=0; を設定し、自動コミットをオフにする必要があります。0なら手動コミット、1なら自動コミットです。

例題で検証する 

例1.

 主キーidを条件にして問い合わせを行い、別のトランザクションを開いてデータを更新すると、更新がブロックされ、ロックが追加され、問い合わせを行うid1の行データがロックされます。

 図1は最初のトランザクションを示し、トランザクションはコミットされていない

 図2は2番目のトランザクションで、データを更新しようとしてブロックされたところです。

 図3は2番目のトランザクションで、長い間ロックの取得に失敗し、エラーが報告されています。

例2．

id が 2 の別のデータエントリーの更新を実行するためにトランザクションを開いています。

インスタンス3(インデックス)。

 開始年齢でテーブルを作成すると、ユニークなインデックスが作成されます。

例4．

 通常のフィールドコードで操作する

別のトランザクションで別のデータを更新しに行き、成功すれば行をロックし、失敗すればテーブルをロックすることになります。

結果

クエリ条件がインデックス/プライマリキーを使用している場合、select ......for update は行ロックになります。

通常のフィールド（インデックス/プライマリーキーなし）であれば、select ......for updateでテーブルロックが行われます。

以上、「面接でselect ......の有無を聞かれた件」をお送りしました。...更新のためにテーブルをロックしたり、行の記事をロックするかどうか、このインタビューに導入され、より関連する更新コンテンツの選択以前の記事のスクリプトのホームを検索してくださいまたは次の関連記事を閲覧し続けるあなたは将来的に多くのスクリプトのホームをサポートすることを願っています