DELETE したはずの行が SELECT で返り続ける ときに何を疑うか

この記事は Dress Code Advent Calendar 2026/07 の 12本目の記事です。 こんにちは、Dress Code株式会社 でプロダクトエンジニアをやっているなたこんです。 データベース周りで個人的にハマったことを紹介します。 更新したはずのデータが読み取り時に古いまま返ってきたとき、何をどの順で疑えばよいかを、実際の事例に沿って整理します。 TL;DR 「テーブルから DELETE したはずの行が、SELECT で返り続ける」という事象に遭遇した。確認できた状況は次の通り。 該当クエリが主キー被覆だったため、実行計画が index-only scan になっていた ORM の設定により、該当クエリは reader に流れていた 大量 DELETE の直後、reader でだけ削除済みの行が返り続けた（primary では返らない） reader で index-

[taku112hoge]

あとで勉強したい

[simplememofast]

index-only scanは可視性確認をヒープでなくVMへの信頼で省く経路。被覆索引による高速化が、readerのVMが古いままだと誤答の穴になる。最適化が正しさの前提を外している

[retarded]

AWSに問い合わせたら？

[ryousanngata]

操作だけ見るとよくあるしシンプルだから起きるならもっといろんなところで言われるだろうし何か見落としがありそうに思った。定期ジョブの作業を手動でやって再現するかとか試せそうなこともまだありそう。

[jksy]

コミットしてないんじゃないかなぁ

[strawberryhunter]

原因がわからなかったのか。どこかにバグがあるんだろうね。遭遇したくないバグ。