都内で働くSEの技術的なひとりごと / Technical soliloquy of System Engineer working in Tokyo

都内でサラリーマンやってます。SQL Server を中心とした (2023年からは Azure も。) マイクロソフト系(たまに、OSS系などマイクロソフト以外の技術も...)の技術的なことについて書いています。日々の仕事の中で、気になったことを技術要素関係なく気まぐれに選んでいるので記事内容は開発言語、インフラ等ばらばらです。なお、当ブログで発信、発言は私個人のものであり、所属する組織、企業、団体等とは何のかかわりもございません。ブログの内容もきちんと検証して使用してください。英語の勉強のため、英語の

実行プランの読み方をまとめてみる - その9 ( Scan しているオペレーターがないからといって、安心してはいけません ) -

 年末・年始にかけてお仕事でした。ゴールデンウィークがお仕事でなくなるのも少し萎えますが、年末・年始がなくなるのはかなり萎えますね。やはりきちんと休みを取りたいものです。来年以降もこのような状態が続きそうです... この状態から脱却するには、会社・業界を変えるしかないんでしょうね(笑)

 さて、今回は実行プランを見ながらどのようにチューニングを行うか簡単に説明します。下図の実行プランを見てください。一見、Scan もありませんし問題のない実行プランに見えます。この実行プランのクエリを実際運用環境で実行させると、平均 15 秒程度かかっていました。下図の実行プランが示す通り単純な検索ではありませんが、遅いですよね。
f:id:koogucc11:20170107170127p:plain

 よく見ると、キー参照のコストが 62% とかなり高いです。Index Seek と合わせると、全体の 90% を占めることになります。他にも負荷の高い処理を実行しているにもかかわらず、このコストの高さは少し変です。
f:id:koogucc11:20170107171023p:plain

 ①と Hash 結合して、②の結果件数がかなり減少しているため、キー参照前に ① の条件が適用できないかインデックスの並びを調整します。
f:id:koogucc11:20170107200643p:plain 

 インデックスの並びを変えることによって、全体のプランは下図のように変化しました。
f:id:koogucc11:20170107170155p:plain

 キー参照前に、的確にデータを絞り込めるようになったため、キー参照のコストが 2% まで減少しています。
f:id:koogucc11:20170107201016p:plain

 上記のチューニングの結果、どの程度の改善があったかを簡単に確認してみましょう。結果は明らかですね。改善後は 2 秒程度で処理されるようになりました。

  • 改善前
    f:id:koogucc11:20170107201721p:plain
  • 改善後
    f:id:koogucc11:20170107201730p:plain

 実行プランから SQL Server がどのようにデータを取得し、処理しているかを的確に判断し、最適なインデックスを作成するようにしましょう。(簡単に言ってしまいましたが、そんなことが簡単にできるならデータベースチューニングなんて仕事必要ないんでしょう.....)

 大分県の銘菓ザビエル。美味しいですよ。

大分の代表銘菓 ざびえる本舗 「ざびえる18個入」

大分の代表銘菓 ざびえる本舗 「ざびえる18個入」

 別府温泉行きたかった.....

るるぶ大分 別府 湯布院 くじゅう'16~'17 (国内シリーズ)

るるぶ大分 別府 湯布院 くじゅう'16~'17 (国内シリーズ)