2019-03-24

anond:20190324094739

SQLアンチパターンではないが、デッドロックについても投げっぱなしのあのSELECT FOR UPDATEの説明はなんなのかね。

1回のトランザクションでupdateを2回発行する場合と1回のSQL複数行のアップデートをする時はデッドロックリスク考慮するってだけで、かなり初心者にはありがたいと思うんだけどね。

1回のトランザクション複数回update文を投げるケース

tA =# begin;
tA =# update t1 set column = value where id = 1;

tB =# begin;
tB =# update t1 set column = value where id = 2;

tA =# update t1 set column = value where id = 2;
tB =# update t1 set column = value where id = 1;
tB =# ERROR:  デッドロックを検出しました

1回のSQL複数行のアップデート文を発行するケース

tA =# begin;
tA =# update t1 set column = value where id = 1;

tB =# begin;
tB =# update t1 set column = value -- update all record

tA =# update t1 set column = value where id = 2;
tA =# ERROR:  デッドロックを検出しました

あと、先勝ち後負けを実現するのはSELECT FOR UPDATEではなく楽観的ロックな。

tA =# begin;
tA =# select updated_at from t1 where id = 1;
         updated_at         
----------------------------
 2019-03-24 06:17:37.952893

tB =# begin;
tB =# select updated_at from t1 where id = 1;
         updated_at         
----------------------------
 2019-03-24 06:17:37.952893

tA =# update t1 set column = column - 1 where id = 1 and update_at = '2019-03-24 06:17:37.952893' and column > 0;
UPDATE 1
tB =# update t1 set column = column - 1 where id = 1 and update_at = '2019-03-24 06:17:37.952893' and column > 0;
UPDATE 0

MySQL存在しないレコード更新しようとするとギャップロックになるから注意な。

記事への反応 -
  • SQLアンチパターンをコピペするアンチパターン

    キーレスエントリー(外部キー嫌い) 外部キー嫌いがアンチパターンなのは同意だが、間違った外部キーの使い方するほうがよっぽどアンチパターンじゃないか? 外部キー貼らなかったこ...

    • anond:20190324094739

      SQLアンチパターンではないが、デッドロックについても投げっぱなしのあのSELECT FOR UPDATEの説明はなんなのかね。 1回のトランザクションでupdateを2回発行する場合と1回のSQLで複数行のア...

      • anond:20190324155924

        投げっぱなしの説明ってのは意味不明だけど、一回のクエリで複数行更新や削除するのは確かにデッドロックの温床になりそうだね。 クエリの順番性次第でデッドロックになるって知っ...

    • anond:20190324094739

      削除フラグ持たせてユーザ名を「退会済みユーザ」に上書きしたろ! ↑ ダメなん?

      • anond:20190324095338

        特別な理由があればいいと思うが、基本、nullableカラム持ったり状態をカラムに記録するのはアンチパターンらしいよ。 https://www.slideshare.net/t_wada/ronsakucasual https://qiita.com/Jxck_/items/156d0a231...

        • anond:20190324113947

          これDB屋の自己満足だよな 顧客の要望はたいていこの3つで 1.退職などの理由で無効化したIDは処理に含めない(ただしオプションで含める機能を付ける) 2.無効化を解除することもある...

      • anond:20190324095338

        そいうのは、削除フラグと言わずに、退会フラグ と言いなさい。

    • anond:20190324094739

      大規模案件ほどシャーディングが前提になるから、 外部キー制約の出る幕なんて無いね

記事への反応(ブックマークコメント)

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん