【セッションレポート】「SQL実行計画 – 主要RDBMS製品の比較(Oracle, MySQL, PostgreSQL)」に参加しました

はじめに

本記事はDB Tech Showcase 2024 の1日目(7/11)において COSOL の渡部さんが講演された「SQL実行計画 – 主要RDBMS製品の比較(Oracle, MySQL, PostgreSQL)」のレポートです。

公式セッション紹介

Oracle, MySQL, PostgreSQLを対象に、実行計画に関連することがらを比較することで、データベースに関する理解を深めることを狙ったセッションです。
セッション全体としてのストーリーは特になく、気になった点をピックアップしてお話しする形で進めます。
いずれかのRDBMS製品の実行計画についてある程度の知識があることを前提とします。上級者向けのセッションと位置づけ、懇切丁寧には説明しません。

セッション資料

• dbts2024発表資料 SQL実行計画 - 主要RDBMS製品の比較(Oracle, MySQL, PostgreSQL)

概要／おすすめポイント

このセッションではSQLの実行計画に絞ってOracle Database, MySQL, PostgreSQLの比較を実施しています。データベースエンジンの比較では、構文やデータ型、関数などの比較はたまにありますが、SQLの実行計画自体の比較を見るのは初めてでしたので興味深かったです。
また、「見積時の実行計画」と「実行時の実行計画」の違いや 出力行数ではなく アクセス行数 を確認しましょう、といったような実際に実行計画を確認するときに どっちだっけ？ と迷ってしまうような点にアプローチされているので、実行計画をあまり見ない方にもイメージしやすいと思います。

渡部さんがOracle DatabaseのSpecialistであり、Oracle Databaseエンジニアの観点から他のデータベースエンジンについて述べられています。私自身と同じ視点になるので、(私には)とても判りやすかったです。

セッション内容の紹介

実行計画の説明から、それぞれのデータベースエンジンにおける実行計画の取得方法、見方について簡潔に説明されています。また、索引アクセスと結合アルゴリズムについても説明されているため、通常チューニングとしてはよくある「索引が利用されているか見てくれない？」とかには対応できるようになると思われます。

以下私が良いな、と思ったトピックについて記します。

• 実行計画＋統計の取得方法
  • 実行計画の予測と実測についての説明と、それぞれの取得方法、何に着目すべきかについて述べられていますので、最初によくある予測(estimated)だけ見てなかなか改善されないな、といったところで時間を使ってしまうようなことが避けられます
• 実行計画の読み方
  • (MySQLやPostgreSQLでは)マニュアルにもきちんと記載されていない実行計画のツリー構造の見方を、実際に検証結果を踏まえて説明されているため、実際に取得した実行計画を読むためのガイドにもなります
  • 統計の見方についても触れているため、実際の出力に対して怪しいところを見つけることができるようになります

もちろんそれぞれの中身について深く解説しているわけではないですが、実行計画自体は例え長い実行計画でも順番に見ていくことができますので、見方・順番についてさえ把握していれば、時間をかけて見ていくことである程度「この辺が問題なのでは？」というあたりをつけることはできると考えており、その目的は達成されているのでは、と考えてます。

まとめ

内容については セッション資料 からダウンロードして頂ければと思いますが、統計などの考え方含めて一読しておくことで、自身で触ったことがないデータベースエンジンについても理解が深まると考えてます。

なお、「主要4種データベース製品（Oracle、MySQL、PostgreSQL、MS SQL Server）の相違点比較と 異種データベース製品活用における課題と解決」という資料も同じ場所からダウンロードできますので一緒に確認しておくとより理解が深まると思います。

おまけ（実行計画の見方簡易版）

業務系のシステム(OLTP系)で実行計画を見るとき、まずは以下に着目すると良いと考えてます。

1. FULL SCANがないか？(INDEXが利用されてほしい)
2. 1行取り出すのにINDEX RANGE SCANが利用されてないか？(UNIQUE SCANが利用されてほしい)

いずれも適切な索引が作成されているか？利用されているか？という観点になります。
そんな初歩は大丈夫でしょ、と思われる方もいらっしゃると思いますが意外と統計情報が適切なタイミングでとられてない、などでこのような状態になっていることがあります。基本の確認という事でまずはこの辺を確認すると良いと思ってます。

これは私自身のTIPSですので、ご参考まで。。

おまけ（システムリリース時の統計情報取得のタイミング）

性能テスト等を潜り抜け十分な性能を確保しているシステムでも、たまにリリース時に「性能が出ない！」というトラブルが発生することがあります。
大体、ゼロ件の状態で意図せず統計情報が取得されてしまった、というような状況で発生します。
特にリリース時において、ヒストリカルなデータはデータ量がある場合でも、トランザクショナルなデータ(例えば今日の取引データ)のようなものがゼロ件で始まる場合に、「リリースなので念のため全テーブル統計情報を取りましょう！」のようなことを実施してしまうと発生してしまう場合があります。
本質的にはどのテーブルがどのような状況か把握しておくことが大事で、それぞれのテーブルに対していつ統計情報を取るべきなのかを認識して計画しておくことで防ぐことができます。
また、リハーサルで本番と同じアクションをやって確認しておく、という事で流出を防ぐことができます。

こちらも私自身のTIPSですので、ご参考まで。。