ノンリピータブルリード（non-repeatable read）は、データベースシステムにおけるトランザクションの一貫性を損なう代表的な問題の一つです。
複数のトランザクションが同時に動作する状況で発生しやすく、データ整合性に影響を与えるため、正確な理解と適切な対策が必要不可欠です。
本記事では、ノンリピータブルリードの仕組みと発生条件、他の類似問題との違い、実際の防止方法について、ITエンジニア向けに詳しく解説します。
ノンリピータブルリードとは何か？
定義と基本的な現象
ノンリピータブルリードとは、あるトランザクションが同じレコードを複数回読み込む際に、その間に他のトランザクションによってレコードが更新され、同一トランザクション内で異なる値が返ってくる状態を指します。
これは一貫性（Consistency）や分離性（Isolation）といったトランザクションのACID特性の「I（Isolation）」に関わる問題であり、読んだはずのデータが途中で変わってしまうことで、アプリケーションの誤動作を引き起こす可能性があります。
具体的な例
このように、トランザクションA内で同じSQLを実行したにも関わらず結果が異なるため、予期せぬ動作や不整合が生じます。
類似するトランザクション問題との比較
ダーティリード（dirty read）
-
他のトランザクションがコミットしていないデータを読み取ってしまう現象。
-
未確定なデータを参照するため、最終的にロールバックされる可能性があり、より深刻。
ファントムリード（phantom read）
-
同じクエリを複数回実行した際、レコードの追加・削除によって結果セットが変化する現象。
-
ノンリピータブルリードは「既存レコードの更新」による差異、ファントムリードは「行数の増減」による差異。
ノンリピータブルリードの防止方法
トランザクション分離レベルの選択
トランザクション分離レベルを適切に設定することで、ノンリピータブルリードの発生を防ぐことが可能です。
以下の順で厳密性が高まります：
-
READ UNCOMMITTED（最低）
-
READ COMMITTED
-
REPEATABLE READ ← ★ノンリピータブルリードを防止
-
SERIALIZABLE（最も厳格）
REPEATABLE READを指定すると、トランザクションが開始された時点のスナップショットを維持し、他のトランザクションによる更新の影響を受けなくなります。
アプリケーション設計上の工夫
-
再読込みが不要な設計にする
-
必要なデータは最初に一括で読み込む
-
トランザクションの保持時間を短縮して、競合の発生を最小限に
実運用における注意点
パフォーマンスとのトレードオフ
REPEATABLE READ以上の分離レベルを使用すると、同時実行性能（コンカレンシー）が低下します。
例えば：
-
ロック競合の発生
-
デッドロックのリスク増加
-
レスポンスタイムの悪化
そのため、業務要件によってはREAD COMMITTEDでも十分な場合があり、要件とパフォーマンスのバランスを見極めて選定する必要があります。
データベースの種類ごとの違い
-
MySQL（InnoDB）：REPEATABLE READがデフォルト
-
PostgreSQL：READ COMMITTEDがデフォルト（MVCCにより別方式で制御）
-
Oracle：一貫性読み取り（Consistent Read）により同様の問題を回避
まとめ
ノンリピータブルリード（non-repeatable read）は、データベースにおいて同じレコードを複数回読み込んだ際、途中でデータが更新されてしまうことで一貫性が失われる現象です。
REPEATABLE READ以上の分離レベルを設定することで防止できますが、同時実行性能とのバランスを考慮する必要があります。
データ整合性が求められるシステムでは、適切なトランザクション管理が極めて重要です。
ノンリピータブルリードのメカニズムを正しく理解し、業務要件に応じた設計・運用を行うことが、堅牢で信頼性の高いアプリケーション開発の鍵となります。