「クエリが返ってこない」「タイムアウトばかり」のとき、実体がブロッキング（誰かがロックを持ったまま、別セッションが待たされている）であることが多い。デッドロックと違い、自動解消されず待ち続ける。
先に結論
- 見るべきはヘッドブロッカー（鎖の先頭でロックを保持しているセッション）
- 待っている側を殺しても、原因セッションが残れば再発する
- 活動モニタや動的管理ビューで「誰が・何を・どれくらい」を取る
- 根本はトランザクション長・索引・取得範囲の見直し
ざっくり見る手順
- SSMS の活動モニタで「ブロックされている」プロセスを開く
- 待ち種別がロック系か（PAGE/KEY/RID など）を確認
- ブロックしているセッション ID をたどり、先頭まで遡る
- 先頭セッションの実行中テキスト・開始時刻・オープン中トランザクション有無を控える
- アプリ側ならリクエスト ID・ユーザー操作と紐付ける
現場でありがちなパターン
- 画面操作の途中で長いトランザクション（ユーザー入力待ちを含む）
- 一括更新が広い範囲のロックを長時間保持
- 索引不足でスキャンしながら更新し、ロック範囲が広がる
- 未コミットのままコネクションがアプリに返却されている
関連: デッドロック概要と対策（相互待ちとの違い整理）
対処の優先順位
- 緊急時のみ先頭セッションの中断を検討（業務影響を確認）
- 恒久策はトランザクション短縮・必要行のみ更新・適切な索引
- 読み取り側の分離レベル変更は副作用があるので最後の手段寄り
- 再現時間帯のバッチスケジュールをずらすだけでも効くことがある
ざっくりまとめ
- 待つ側より止める側（ヘッド）を見る
- 活動モニタ／DMV で鎖をたどる
- 殺すのは応急。長さと範囲の設計が本丸
関連記事