読み取りがロック待ちで止まるとき、ヒントでロックを回避したくなる。いわゆる NOLOCK（読み取り未コミット相当）だ。速く見える一方で、消えたり二重に見えたりする読み取りが混ざりうる。
先に結論
- 使いたくなる … 粗い集計・監視・多少のズレが許容される画面
- 避けたい … 金額・在庫・承認状態など「正しさ必須」の読み
- ブロッキング対策の主役にはしない。根本はトランザクション短縮と索引
- 代替としてスナップショット系分離レベルの方が安全なことが多い
何が起きうるか
- まだ確定していない変更を読んでしまう
- 途中でロールバックされた行を見たことになる
- ページ移動のタイミングで行の取りこぼし・重複が起きうる
- 「たまに数字が合わない」系の再現しづらい不具合の温床
使うなら守ること
- 用途をコメント／設計書に明記（なぜズレてよいか）
- 書き込みパスや整合性チェックには使わない
- チーム内で「禁止／条件付き許可」を決める
- まずはヘッドブロッカーと遅い文の改善を優先
関連: デッドロック / ブロッキング調査記事（同サイトのブロッキング解説）
代替の方向
- READ COMMITTED SNAPSHOT 等で読み取り側のロック待ちを減らす
- レポートはレプリカ／別時間帯のスナップに寄せる
- 必要な列・行だけ読む（ロック範囲を狭くする）
- 長い書き込みを分割し、待ち時間そのものを短くする
ざっくりまとめ
- 速さのためのヒントだが、正しさを犠牲にする
- 許容できる読みに限定。基幹更新の前提にはしない
- 分離レベルとクエリ改善の方が本筋
関連記事