テクノロジー

90秒かかるDELETE文の原因を探る【PostgreSQL】 - エムスリーテックブログ

1: Sampo 2025/07/25 14:29

あっそうかDMLはEXPLAINしてボトルネック一発でわかるとかできないわけね(日頃問い合わせのパフォーマンスしか考えないからDML側が重いときのことって考えたことなかった)

2: mooonymann 2025/07/26 03:05

“部分インデックスが使用されるためにはその定義に含まれるWHERE句の条件(この場合deleted_at IS NULL)が問い合わせの条件に包含される必要があります。また、他にインデックスはありましたがuser_idを先頭に指定しないイン

3: khtno73 2025/07/26 07:56

業務パッケージやアドオンだと不整合防ぐためにこういうのはDELETE前に各テーブルに存在チェックしてアラートだすロジック入れてること多いんであんま出くわさないが、確かにこれ遭遇したらハマりそうだなあ。

4: Wafer 2025/07/26 08:14

ほへー。deleteは禁書扱いなので論理削除やパーティションで区切ったりテーブルそのものをdrop/truncateしたりしてた

5: remonoil 2025/07/26 10:57

"オチ:結局はインデックス" 初手でSELECT文に変えてのEXPLAIN ANALYZEしつつ、DELETE文特有のトリガー等にも気をつけよう、ということか

6: hiroshe 2025/07/26 11:06

こういうの解決すんのめっちゃ気持ちええよな

7: tettekete37564 2025/07/26 13:49

このレベルは全然分からん

8: pj_lim 2025/07/26 18:50

結局インデックスやんけ...