SQL SELECTの実行速度が遅い場合の解決方法

Question

RedShiftにてSELECTクエリの実行速度が遅く困っています。
SQLのチューニングの方法についてあまり詳しくなく、スピード改善の参考になる記事や
クエリ中の遅くなっていると予想される箇所などよろしければお伺いしたいです。

---

問題が出ているのは以下の入力フォームで複数の値を同時に検索することができるSELECTです。
複数のテーブルを結合して、指定のIDかつ最新のものを１件取得するSQLになります。
phpでWHERE　OR OR OR・・・で検索条件を繋いでおり。検索条件が百件を超えると遅くなってしまいます。

SELECT stores.*,categories.category,cities.cityname
FROM(SELECT storecode,buildcode,lat.lng,date,rank() OVER (PARTITION BY storecode ORDER BY date DESC) AS rank
              FROM stores
　　　　　　　　 WHERE (storecode = 'A01' AND date <= '2021-04-19') 
              OR (storecode = 'B02' AND date <= '2021-04-20') 
　　　　　　　　 OR ・・・・. OR　・・・・
              AS stores
LEFT OUTER JOIN  categories ON stores.buildcode = categories.buildcode
LEFT OUTER JOIN  meshcode ON （計算の為省略) = cities.meshcode
WHERE rank = 1

上記SQLについては以前質問し、以下回答があったSQLになります。
https://teratail.com/questions/334027

実行計画は下記の通りになります。
見たことのないような桁になり検索が全く動きません。。。

   Outer Dist Key: ((((((floor((("outer".lat * 60::double precision) / 40::double precision)))::text || (floor(("outer".lng - 100::double precision)))::text) || (floor(((("outer".lat * 60::double precisi)::text)
   Hash Cond: ("outer"."?column10?" = ("inner".meshcode)::text)
   ->  XN Hash Left Join DS_DIST_ALL_NONE  (cost=1000010812381.25..1000010812383.59 rows=1 width=245)
         Hash Cond: (("outer".buildcode)::text = ("inner".buildcode)::text)
         ->  XN Subquery Scan l  (cost=1000010812372.86..1000010812375.18 rows=1 width=207)
               Filter: (rank = 1)
               ->  XN Unique  (cost=1000010812372.86..1000010812374.78 rows=32 width=65)
                     ->  XN Window  (cost=1000010812372.86..1000010812373.94 rows=48 width=65)
                           Partition: storecode
                           Order: date
                           ->  XN Sort  (cost=1000010812372.86..1000010812372.98 rows=48 width=65)
                                 Sort Key: storecode, date
                                 ->  XN Seq Scan on stores  (cost=0.00..10812371.52 rows=48 width=65)
                                       Filter: (((storecode)::text = 'A01'::text) AND (date <= '2021-05-11'::date))
         ->  XN Hash  (cost=6.71..6.71 rows=671 width=59)
               ->  XN Seq Scan on categories  (cost=0.00..6.71 rows=671 width=59)
   ->  XN Hash  (cost=3872.85..3872.85 rows=387285 width=40)
         ->  XN Seq Scan on cities  (cost=0.00..3872.85 rows=387285 width=40)

Comments

[sazi]

実行計画の結果を追記して下さい。

それから、orの条件が100件を超えると遅いのですか？
それとも、結果が100件を超えると遅いのですか？

[yowayowanitohei]

sazi様

ご指摘に気づかず申し訳ございません。
explainにて実行計画を取得し追記させていただきました。

メッシュコードはstoresテーブルから取得した緯度経度を桁ごとに計算し連結することで求めています。
求めた結果を元にcitiesテーブルより町名を取得しています。

Answer 1

実行計画からは以下のSQL部分が遅いのが分かります

SELECT storecode,buildcode,lat.lng,date
      ,rank() OVER (PARTITION BY storecode ORDER BY date DESC) AS rank
FROM stores
WHERE (storecode = 'A01' AND date <= '2021-04-19') 
   OR (storecode = 'B02' AND date <= '2021-04-20') 
　 OR ・・・・. OR　・・・・

取り敢えずは、storesに**(storecode, date desc)**のインデックスを追加してみてください。

改善しないようなら、インデックス付きの条件用の一時テーブルを使用するとかですね。

Comments

[yowayowanitohei]

sazi様

ご回答ありがとうございます。
インデックスちゃんとつけてみます！
質問してからこの５日間色々試してみたのですが、
ご指摘の部分をUNIONで検索を何度も結合する場合速度改善することはあるのでしょうか。。。。

何度もすみませんがどうぞよろしくお願い致します。

[sazi]

状況からは、storesの件数が大量だと推測されますから、unionだろうがインデックスが無ければ改善しないと思います。
今時、orをunion展開したからと言って高速になるようなDBMSは無いでしょう。
それから、storesに対してのVACUUMの実施はお勧めします。※かなり時間が掛かる事が予想される。
storesに大量にdeleteしている状況だと、不要データが邪魔をしてる可能性がありますので。