Kichijoji.pm Online #30

1. 時を駆ける
INSERT

2. 発表者：わいとん（@ytnobody）





3. 今朝は海ほたるにいました

4. アジェンダ





5. INSERTとは何か

6. INSERT 


7. INSERTのよくある例
 INSERT INTO "account" ("name", "email")
VALUES ('ytnobody', 'ytnobody@gamil.com’)
;

8. 本当に正しいINSERTと言えるか？



9. たしかにTRANSACTIONは重要。

 INSERT INTO "account" ("name", "email")
VALUES ('ytnobody', 'ytnobody@gamil.com’)
;
 INSERT INTO "account" ("name", "email")
VALUES ('ytnobody', 'ytnobody@gmail.com’)
;

10. TABLE定義次第では正しくあり、誤りでもある




11. 例えばこんなTABLEが相手なら大丈夫そう
Column Type NULL SETTINGS, KEY, ETC…
id INT UNSIGNED NO PRIMARY KEY, AUTO INCREMENT
name VARCHAR(255) NO
email VARCHAR(255) NO UNIQUE
description TEXT YES
updated_at DATETIME NO DEFAULT CURRENT_TIMESTAMP ON
UPDATE CURRENT_TIMESTAMP

12. あるいはこんなTABLEかもしれないですね。
Column Type NULL SETTINGS, KEY, ETC…
name VARCHAR(255) NO
email VARCHAR(255) NO PRIMARY KEY

13. 既に格納されているデータとの関係性によっては
ダメかもしれない



14. ではRDBMSはどうやって既存データとの整合性を
担保しているのか。
キー値取得
• INSERTされるデータのうち、UNIQUEおよびPRIMARY KEYなカラムの値（キー値）を抜き出す
キー値照合
• Intention eXclusive Lock（IX） を設定する（MySQL InnoDBの場合）
• 抜き出したキー値と同じキー値をもつレコードが存在しないか探す
• 照合が終わったらIXを解除する
データ登録 or 拒
否
• 同一キーをもつレコードがいなければ、データを登録する
• 同一キーをもつレコードがいれば、エラーを返してデータ登録を拒否する

15. INSERTには大なり小なりのロックが伴う





16. PRIMARY KEYと
AUTO INCREMENT

17. PRIMARY KEYにAUTO INCREMENTを
指定することで採番を自動化する


18. AUTO INCREMENTのIDは重複しないことが保証さ
れているが・・・



19. ではRDBMSはどうやってAUTO INCREMENT値の
整合性を担保しているのか。
ロックを設定
• AUTO-INC Lock を設定する（MySQL InnoDBの場合）
• これで他のスレッドなどによりAUTO INCREMENT値が勝手に加算されることを防ぐ
値取得
• TABLEが持っている「次のAUTO INCREMENT値」を取得する
• 次回のINSERTに備えて「次のAUTO INCREMENT値」を加算しておく
データ登録・
ロック解除
• データを登録時にAUTO INCREMENT値を使ってデータを登録する
• AUTO-INC Lockを解除する（MySQL InnoDBの場合）

20. AUTO INCREMENTな値の影には
ロックが活躍している



21. 塵も積もれば山となる





22. サロゲートキーの
意義と設計

23. サロゲートキーとは




24. サロゲートキーの一意性担保の方法あれこれ








25. むやみにRDBMSの自動採番機能に頼らない、
という考え方



26. よりよいサロゲートキーを考える



 ulid/spec: The canonical spec for ulid (github.com)





27. まとめ

28. まとめ






29. マクワウリ
グラスに見立て
ロックかな

30. Any Questions?