ロック概論 - RDB
最終更新日: 2026-08-25
TOP(About this memo)) > 一覧(RDB) > ロック概論
ロック概論
楽観ロックと悲観ロック
- (参考) 排他制御 - TERASOLUNA — かなり詳しく書かれている記事。
- 楽観ロック
- データそのものに対してロックは行わずに、更新対象のデータが取得時と同じ状態であることを確認してから更新することで、データの整合性を保証する手法。
- 悲観ロック
- 更新対象のデータを取得する際にロックをかけることで、他のトランザクションから更新されないようにする手法。
共有ロック、排他ロック
MySQLとPostgreSQLのスタンスの違い
MySQLでもPostgreSQLでも、トランザクション中のUPDATE、DELETE、およびロック付きSELECTにはロックがかかる。両者ともロックが競合したら待機する（NOWAITをつけた場合は即時エラーを返す）。
ただし、REPEATABLE READレベル以上でのアプローチが異なる。
- MySQLは、ロック取得時に取得するデータが、トランザクションの最初の読み取り時のバージョンではなく「その時点の最新のバージョン」になる。
- これはロストアップデートをさせないアプローチ。
- REPEATABLE READレベルであるにもかかわらずこの挙動をしているため、分離レベルを一部落としていると解釈することもできる。すなわち、プレーンSELECTの「一貫性読み取り」との整合性がずれていることを意味する。
- PostgreSQLは、ロック取得時に取得するデータがトランザクションの最初の読み取り時のバージョンになる。
- ロストアップデートは競合検査によって行い、検知された場合はエラーになる。
(IMO) PostgreSQLは楽観的制御に重きを置き、MySQLは悲観的制御に重きを置いている、という整理がしっくりくる。
アドバイザリーロック（勧告的ロック）
明確な定義は見つからなかったが、(IMO)「アプリケーション側でコントロールできることに置いたロック」といった解釈をしている。
例えば、PostgreSQLで用意されている pg_advisory_lock 関数は、任意のbigintを渡してロックとして扱うことができる。
PostgreSQLは、アプリケーション独自の意味を持つロックを生成する手法を提供します。これは、その使用に関してシステムによる制限がないこと、つまり、正しい使用に関してはアプリケーションが責任を持つことから勧告的ロックと呼ばれます。