sqlでwith句の書き方や使い方をお探しではありませんか? 本記事では、with句の書き方や使い方をサンプルを交えて分かりやすく解説をしております。ぜひ参考にしてください。 例としてsql 副問い合わせの基本を理解するで扱ったfrom句の副問い合わせのsqlをおさらいします。, WITH dn(n) as ( select 0 from dual union all select n + 1 from dn where n < add_months (trunc (sysdate, 'yyyy'), 12) - trunc (sysdate, 'yyyy') - 1 ) select trunc (sysdate, 'yyyy') + n from dn; Oracle 10g で再帰を使うと「ORA-32033: 列はサポートされていません。」 とエラーになる。 ストアドしないファンクションを組み込んだ月締めカレンダーの例 oracle sqlのselect文が遅いとき、or句の置き換え・書き換えによってチューニングできる場合があります。下記のようなselect文が遅い場合は、or句をunion allに置き換えてみましょう。union allの方が高速に結果を返してくれる場合は、union allを使うことをオススメします。, sqlにおいて、サブクエリは可読性下がるからwith句を使えという話をしばしば聞く。 ただ、最近あえてサブクエリで記述している人がいたので with句とサブクエリで何が違うか について考えてみた。 同じ抽出内容だが片方はwith句、片方はサブクエリで書いた以下のsqlをベースに話す。 cpu 時間 = 766 ミリ秒、経過時間 = 9189 ミリ秒 実行計画. http://www.orafaq.com/parms/parm2088.htm, ITアーキテクト。流通小売業の基幹系システム構築に従事。 ・CBOの場合はアクセス順が変わらない場合がある(オプティマイザの判断), 今回の検証では、オプティマイザ・ヒントを利用して「from句の順番=アクセスする順番」が変わることで、パフォーマンスに違いが出ることが確認できました。 実行SQLの準備ですが、前述したようにCBOでは自動的に最適なアクセスパスを判断するため、from句の順番を変えても実行計画が変わらず、パフォーマンスに影響し辛くなっています。, 実際に実行計画を確認してみましょう。 今回の検証では単純なテーブルと、単純な結合方法でのSQL実行であったため、このようなパフォーマンスの差が顕著に出たものと考えますが、パフォーマンスの良い順番にアクセスするという考えは正しかったということになります。, ただ、RBOを採用しているDBでは自動的に行っている部分が大きく、なかなか意識しない部分になりますので、もしCBOを採用する場合には少しでも参考にしていただければ幸いです。. また、対象のデータベースは「Oracle」とします。, と、ここまで説明してご存知の方からはすぐに、「Oracleのバージョンやオプティマイザの種類によって結果が異なるのではないか。」とご指摘をいただきます。 with句でviewを作成し重複するsql文をまとめる方法を説明します。with句を使えば1つの副問い合わせ(sql)を複数の箇所で使いまわすことができます。 しかし、この説を信じてチューニングしても、思うように効果を得られなかったケースがあるはずです。, まず誤解を解いておきたいのは、「待機イベント=“悪”」という図式です。待機イベントはある状態を示しているに過ぎません。そして、待機イベントはアプリケーションまで含めた、システムのアーキテクチャの観点から捉えるべきものです。, 詳しい理由については後述します。ここは“急がば回れ”で、基礎知識を再確認するためにも、アーキテクチャの説明から始めます。, なお、本稿では、一時的な性能悪化を調査する方法など、ほかの書籍や記事では紹介されていないノウハウの解説を多くしました。また、内容をノウハウの紹介に集中しているため、コマンドは詳しく解説していません。コマンドについては、ほかの書籍や記事をご覧ください。また、話を複雑にしないため、マルチスレッドサーバー構成(MTS構成)は今回扱いません。記事中のスクリプトなどは、特に注意書きがない限り、Oracle9i R2で確認しています。, 注1:待機イベントについては後ほど説明します。今は「待ち」のことだと思ってください。つまり、「待機イベントの値が大きい=待ちが多い」ということです。, チューニングの際、皆さんは「Oracleの仕組みはこうだから、こうすればいいだろう」と頭の中で考えていますよね。世の中 でよく言われるように、仕組みを図(イメージ)で書くことができれば、それを「理解している」と言って良いと思います。皆さんはOracleの動作モデルを図で描けますか?この先の解説を理解するためにも、ここで確認しておきましょう。, ただし、 Oracleのセミナー(研修)などで学んだ方もいらっしゃると思います。理解しているという方は図だけを見て、次節「システムのパフォーマンス測定方法とOracleの比較」に進んでください。, まず、いちばん簡単なキャッシュに載っているデータをSELECTするだけのケースです(図1)。「Oracleクライアントプロセス」が、アプリケーションサーバー(以下、APサーバー)などのOracleから見たクライアントです。OracleクライアントからSQL文が送信され、サーバープロセスがそれを受信して、Oracleのバッファキャッシュにあるデータにアクセスし、SQL文の結果を作ります。, 次に、データがキャッシュにないケースを説明します(図2)。先ほどと異なるのは、SQL文の処理に必要なデータをディスクからサーバープロセスが読み込むことです。先ほどと同様にサーバープロセスがSQL文の処理を一手に引き受けています。, 最後に、データ更新(UPDATE)時の動作について説明します(図3)。すでにキャッシュにデータは載っているものとします。, Oracleクライアントプロセスから見ると、サーバープロセスが処理を一手に引き受けており、主なプレーヤーであることは変わりありません。サーバープロセスがデータを変更した後、OracleクライアントプロセスへUPDATEが終了したことを送信します。それを確認して、OracleクライアントプロセスはCOMMITをサーバープロセスに送信します。, 次に、サーバープロセスはログをログファイルに書きますが、自分自身では書くことができないため、ログライター(LGWR:ログを書き出す役目のプロセス)に書き出しを依頼します。サーバープロセスはログライターが書き終わるまで待機します。ログライターから書き終わりの通知がサーバープロセスに届くと、サーバープロセスはOracleクライアントプロセスにCOMMIT終了を通知します。, システムのパフォーマンス測定では、タイムスタンプを主な処理ポイントで取得したりします。例えば、一般的なWebシステムでは、次のような計測ポイントがあるでしょう。, まず、Webブラウザから出たリクエストがAPサーバーにいつ到着し、さらにAPサーバーで処理されDBへSQL文を発行したのはいつで、DBからSQL文の結果が戻ってきたのはいつ、APサーバーからブラウザへの送信はいつ、といった具合です(図4)。このよう にタイムスタンプを記録しておけば、どこで時間がかかっているのかが一目瞭然です。, しかし、広く使われている「STATSPACK」というパフォーマンス分析ツールを使っても、「SQLトレース(SQL文を調査するツール)」を使っても、Oracleのパフォーマンス情報はサマリーで表示されてしまうため、この図のような計測は行なうことができません。, このように情報をサマリーすることには、メリットとデメリットがあります。メリットとしては、莫大な詳細情報を見ずに(DBサーバー全体の)概要を把握できることがあります。特に、STATSPACKはそのような用途に向いています。SQLトレースはセッション(Oracleクライアントとサーバーの論理的な接続)単位であるものの、SQL文の情報をサマリーとして見ることができます。例えば、同じSQL文が1万回実行されても、情報としては数行から数十行にまとめてくれます。, サマリーのデメリットは、実行したまさにその時の状態を知ることができない点です。実際のシステムにおいては、ずっと同じ状態ということはありえません。例えば、10回に1回だけSQL文の処理が遅延したとします。その場合、STATSPACKのサマリーされた情報では平均値しか見ることができないため、遅延したかどうかすら分かりません。また、遅延していた時にSQL文がDBに届いていたのかも判別できません。SQLトレースもSQL文の情報は表示されますが、いつ実行されたかや、その時どんな待ちが発生したのかは分かりません。, 誤解しないでいただきたいのは、サマリー自体が悪いわけではなく、大切なのは、サマリーをとるケースと、サマリー以外の情報をとるケースとを判断できることです。また、取得した情報の意味や特性を正しく理解することが重要です。, 情報の意味や特性を説明する前に、次はパフォーマンスとは何かを正しく理解する上で大切な、Oracleのアーキテクチャや動作について解説します。, ここでは、STATSPACKやOracleに付属のツールでパフォーマンスデータを見る上で重要なキーワードである「サーバープロセス」と「バックグラウンドプロセス」について説明します。まずは、STATSPACKの出力結果(抜粋)を見てください(LIST1)。, 最初の2つの白抜きのところがサーバープロセス、最後の白抜きのところがバックグラウンドプロセスです。バックグラウンドプロセスの箇所には「Background」と書いてあるので、区別できます。バックグラウンドプロセスとは、サーバープロセスをサポートするプロセスと考えて構いません。サーバープロセスが表で活躍する人(プロセス)で、バックグラウンドプロセスが裏方という役割です(図6)。, 図1や図2と見比べてください。これらの図から分かるように、バックグラウンドプロセスの処理が進まなくても、サーバープロセスの処理さえ遅れなければSQL文は高速に処理されます。つまり、Oracleのパフォーマンスを確認する際は、 サーバープロセスの情報を見ればだいたいは十分です。バックグラウンドプロセスの情報は、バックグランドプロセスが原因でサーバープロセスを待たせてしまっている場合のみ見ればいいのです。, STATSPACKを使って得られる情報(LIST1の白抜きの箇所)は、存在するサーバープロセス(もしくはバックグラウンドプロセス)の合計となっています。そのため、1時間計測しただけなのに、データベースファイルの読み込み(ディスクの読み込み)時間が3時間といった数値を示すことがあります。この「 STATSPACKの情報は存在したプロセスの合計である」という点は非常に重要ですから、よく覚えておいてください。, 「待機」とは、プロセス(セッション)がCPUを使わずに待っている状態のことです。「イベント」とは、直訳すると「出来事」ですから、I/Oやロック競合などのことを指します。誤解を恐れず簡単に言ってしまうと、「プロセスがCPUを使わずに待たなければならない出来事」が「待機イベント」です。, 「cpu used by this session」という統計値がSTATSPACKなどにありますが、これは全サーバープロセスが使用したCPUの合計時間です。動作モデルの図5を使い、「cpu used by this session」と待機イベントの関係を表わすと、図7のようになります。, 例えば、「SQL*Netmessage from client」というイベントがあります。これはDBにとってのクライアント(例えば、SQL*PlusやAPサーバー)からSQL文が来るのをサーバープロセスが待っている状態です。図7では、 ■線部分がSQL*Net message from clientを示しています。アイドル(何もしない)状態であることを意味しているため、SQL文の処理時間には含まれません。つまり、アイドルである待機イベントは通常、無視して構わないものです。, 次に、「db file sequential read」というイベントについて説明しましょう。プロセスはデータベースファイルからランダムI/O 注2でデータ(ブロック)を読み込んでいて、完了するのを待っている状態です。図7では ■線部分が相当します。SQL文を処理するために必要なデータを読み込んでいるわけですから、SQL文の処理時間の中に含まれます。つまり、アイドルでない待機イベントは、注目に値すると言えます。, この待機イベントをチューニングする場合、DBだけを見て解決できることは少なく、視野を広くして「そもそもアプリケーションやSQL文を変更すれば、読み込みを減らせるんじゃないの?」といった発想も求められます。, OLTP系システムであって、パラレル処理をまったく行なっていなければ、図7から分かるように 「cpu used by this session」とアイドルではない待機イベントの合計が、ほぼSQL文の処理にかかった合計時間と言えます 注3。処理されたSQL文の数で割れば、ほぼ1つのSQL文の平均処理時間になります。, このように、待機イベントには 2 種類あり、アイドルの待機イベントは無視して問題なく、アイドルではない待機イベントと「cpu used by this session」の合計がほぼSQL文の処理にかかった合計時間であることを、ここでは理解してください。, 注2:待機イベント名には「sequential(シーケンシャル)」と書いてありますが、実質的にはランダムI/Oです。 Oracleにおける、いわゆるシーケンシャル(順次)I/Oは「db file scattered read」です。, 皆さんは、パフォーマンス情報の取得間隔をどれくらいにしていますか?STATSPACKによる取得(「スナップショット」と呼ばれる)間隔は1時間であったり、OS側のI/O情報も数十分間隔であったりするのではないでしょうか。そのような状況で数十秒から1分程度の遅延が発生したと仮定して、どのようなデータが現われるか考えてみましょう。遅延理由は、「ディスクからの読み込みが1分程度遅延した」とします。 日本オラクル株式会社 コンサルティング統括本部テクノロジーコンサルティング本部 小田 圭二(おだ けいじ) 目次. 【データ件数バリエーション】 今回は、WITH句ごとに materializeヒントを埋め込む対応を取りました。 なぜ一時表にする必要があったか? 今回この対応をしたのは、テーブル(マスタ系データ)の名称どうしの中間一致での結合でのパフォーマンス対応がきっかけでした。 処理時間. まずは生成データを下記の通り設定しました。 インデックスを使わないSQLはパフォーマンスが遅いOracleでパフォーマンスが遅いのにはいくつかの理由があります。パフォーマンスが遅い理由で最も多いのが「SQLの問題」です。SQLを改善すれば、パフォーマンスがよくなって検索時間を短縮でき What is going on with this article? そうなると、SQL分のチューニングが自動的に行われ、from句の順番を考慮する機会はほとんど無くなりつつあります。, では今回の検証は取りやめに……しません!! ・1000件 Copyright © 2008, Oracle Corporation Japan. ・100件 試したところ上手くいかず。(パターンは以下の3パターン) Oracle Database はヒント句を使用する事で、 オプティマイザのアップグレードを行った結果、一部機能のパフォーマンスが落ちてしまった・・・ といったような事も起こりえます。 このような時は一体どのようにすれば良いでしょうか? ヒント句で解決. 今回は、WITH句ごとに materializeヒントを埋め込む対応を取りました。, 今回この対応をしたのは、テーブル(マスタ系データ)の名称どうしの中間一致での結合でのパフォーマンス対応がきっかけでした。 「コストベース・オプティマイザ」 → 「CBO」, 今回は格納されているデータ件数の異なるテーブルを用意し、そのテーブルを結合するSQL文の実行時間を、from句の指定順番を変えながら計測します。, ・サンプルテーブルにそれぞれ100件、100万件のデータを作成 コストベース・オプティマイザ採用のOracle11gでオプティマイザ・ヒントを用いて、「from句の順番=Oracleが検索するテーブルの順番」によって、パフォーマンスにどれくらいの違いが出るのかを検証します。, Oracleのオプティマイザは、データベースへの問い合わせ時にデータに対して最適なアクセス方法を考えてくれる機能です。その種類として、前述しました「ルールベース・オプティマイザ」と「コストベース・オプティマイザ」についても少し触れておきます。, Oracle10g以降はサポートされていないとはいえ、初期化パラメータ次第ではまだRBOを利用できるので、利用しているところは多いかもしれません。 oracle sqlのselect文が遅いとき、or句の置き換え・書き換えによってチューニングできる場合があります。下記のようなselect文が遅い場合は、or句をunion allに置き換えてみましょう。union allの方が高速に結果を返してくれる場合は、union allを使うことをオススメします。 本連載では、Oracleデータベースのパフォーマンス・チューニングの中から、特にSQLのチューニングに注目して、実践レベルの手法を解説する。 パフォーマンスについて WITH 句で別名をつけた場合、1つの名前につき最大1回しか読み込まれないことが保証される。 また、ほとんどの DBMS では SQL を最後まで読み込んだうえで最適化するので、インデックススキャンで済むものは一時テーブルを作成しない。 普通にサブクエリだけをつなげるのと、with句を利用したときのパフォーマンスを比較したサイトもありますね。 IT業界に入ってSQLの学習で初めてサブクエリというもの知ったとき便利なものだなと感じ … 処理時間 『sqlパフォーマンス詳解』の翻訳者の松浦隼人さんに、8つの「sqlが重たくなる原因とその対策」を聞きました。システムのボトルネックになるような「問題のあるsql」を回避するノウハウを学びましょう。 まずはunion句の場合. インデックスを使わないSQLはパフォーマンスが遅いOracleでパフォーマンスが遅いのにはいくつかの理由があります。パフォーマンスが遅い理由で最も多いのが「SQLの問題」です。SQLを改善すれば、パフォーマンスがよくなって検索時間を短縮でき 今回は、WITH句ごとに materializeヒントを埋め込む対応を取りました。 なぜ一時表にする必要があったか? 今回この対応をしたのは、テーブル(マスタ系データ)の名称どうしの中間一致での結合でのパフォーマンス対応がきっかけでした。 オプティマイザーが気を利かせて一時表にせずに、本体の問合せとマージされた実行計画が作られる場合があります。, WITH句のQueryごとに /*+ materialize */ ヒントを埋め込む。, なお「_with_subquery」という隠しパラメータも11gから追加されていて、 門外不出のOracle現場ワザ 第1章 目からウロコのOracleパフォーマンス分析テクニック. ・それぞれ5回実施し、平均時間を採用する この文書はあくまでも参考資料であり、掲載されている情報は予告なしに変更されることがあります。日本オラクル社は本書の内容に関していかなる保証もいたしません。また、本書の内容に関連したいかなる損害についても責任を負いかねます。, Oracleは米国Oracle Corporationの登録商標です。文中に参照されている各製品名及びサービス名は米国Oracle Corporationの商標または登録商標です。その他の製品名及びサービス名はそれぞれの所有者の商標または登録商標の可能性があります。, 1996年日本オラクル入社。人事教育本部にて、新卒や中途採用社員に対し、データベースやOS、ネットワークの講師を5年ほど経験した後、2000年にテクノロジーコンサルティング本部に異動。 テクノロジーのコンサルタントとして、主に大規模ミッションクリティカルシステムを担当。, ポリシーは、「OracleもOS上で動くアプリケーションにすぎない。だから、OS、ストレージ、ネットワークを学ぶべき」。 スキル面の興味は、アーキテクチャ、DBA、インフラ技術、教育、コンサル手法など。, 注4:実体としてのキューを持っていないような待ち行列も含みます。例えば、ラッチはキューで管理されているわけではありません。しかし、レスポンスタイムは待ち行列の特性を持っています。, 世間で一般的なOracleパフォーマンス分析方法の問題点(1) 合計と平均のマジック, 世間で一般的なOracleパフォーマンス分析方法の問題点(2) 瞬間的な待ち行列のマジック, 世間で一般的なOracleパフォーマンス分析方法の問題点(3) 計測ポイントのマジック, 世間で一般的なOracleパフォーマンス分析方法の問題点(2)~瞬間的な待ち行列のマジック, 世間で一般 的なOracleパフォーマンス分析方法の問題点(3)~計測ポイントのマジック, 入力したキーワードの同義語を使用してください。たとえば、「ソフトウェア」の代わりに「アプリケーション」を試してみてください。. 日本オラクル株式会社 コンサルティング統括本部テクノロジーコンサルティング本部 小田 圭二(おだ けいじ), 皆さんの中にも、このような説明を見た方が多いかもしれません。特にチューニング経験が豊富な方は、この説は大体正しいと感じると思います。私の感覚では10回中7回か8回程度正しいのではないでしょうか。 パフォーマンスを低下させる原因の1つは、Oracleの通信オーバーヘッドが高いことです。Oracleは一度にSQL文を1つずつ処理する必要があります。つまり、各SQL文がOracleをコールするので、オーバーヘッドが増加します。 ・データ生成には OBのデータ生成機能を使用, ①データ生成(100件、100万件を用意) ・100000件 ・テーブル結合を含むSELECT文の実行時間を計測 テーブルを結合するようなSQLを実行する際、パフォーマンスを考慮しfrom句で指定するテーブルの順番を考え直すといった場面があるかと思います。 データの内容、件数、処理内容などによっては結果が異なるかと思われますが、今回の検証結果ではデータ件数を考慮した実行SQLのメンテナンスが非常に重要であることがわかりました。, また、from句で指定する順番のうち、一つ目のテーブルに大きく影響を受けるということが確認できました。 sql with句でviewを作成し重複するsql文をまとめる. union句はインデックスのスキャンが2回実行されています。 union句を利用すると、このように条件ごとにテーブルをスキャンする無駄が生じます。 続いてcase式の場合. 処理時間. All rights reserved. そのためTable2の件数をあらかじめ絞り込んでおいた一時表を、WITH句をわざと使用して作成しようとしたのですが、ヒントなしではオプティマイザによって最適化されて一時表が作成されず意図した実行計画にならなかったという経緯です。, materialize ・一つ目にアクセスするテーブルの影響が大きい 普通にサブクエリだけをつなげるのと、with句を利用したときのパフォーマンスを比較したサイトもありますね。 IT業界に入ってSQLの学習で初めてサブクエリというもの知ったとき便利なものだなと感じ … ここでは、ORACLEデータベースのSQLで、WITHの書き方や使い方を紹介します。, WITH句を使うことで、複数回記述されているサブクエリを1つにまとめることが出来ます。, 複数回書かれているサブクエリを1つにまとめることが出来るので、可読性が高くなると言われています。, WITHは非常に便利な反面、使い方を間違えるとパフォーマンス悪化の原因ともなります。WITHを使ったSQLのチューニングについては↓で解説しておりますので参考にしてください。>>WITHを使って遅い場合のチューニング方法, WITHを使うことで複数回書かれている副問合せを1つにまとめて記述することが出来ます。, WITH句はSELECT句の前に「WITH 別名 AS (SELECT )列名 FROM テーブル名)」として使います。具体的には↓のように使います。, 次のSQLでは「(SELECT * FROM tab2 )」という副問合せが2回登場しています。, WITH句を使うことで、2回記述されていた副問合せを「wt1 AS (SELECT * FROM tab2)」として1つにまとめることが出来ました。, WITH句を使うことで、複数回コーディングされているサブクエリを1つにまとめて記述することが出来ます。, WITH句は多用すると、逆にSQLが読みづらくなることもあるので、注意が必要です。, この他にも、SELECT文には様々な機能や使い方があります。詳しくは「【SQL】SELECT文の書き方:サンプル多数あり」で解説していますのでぜひ参考にしてください。. LIKE結合(Table1.col_name1 LIKE '%' || Table2.col_name2 || '%') WITH句で問合せを定義しても、そのWITH句の問合せの利用箇所が1カ所のみの場合には、 Why not register and get more from Qiita? 後述しますが、Oracle10g以降の場合は「ルールベース・オプティマイザ(RBO)」がサポートされなくなり、「コストベース・オプティマイザ(CBO)」が主流となっています。 union句はインデックスのスキャンが2回実行されています。 union句を利用すると、このように条件ごとにテーブルをスキャンする無駄が生じます。 続いてcase式の場合. SQL、SQLチューニング、Oracle、DB設計(概念、論理、物理)、ERD、構造化分析設計、DFD「上げようクオリティ!下げよう勤務時間♪」. Oracle Database はヒント句を使用する事で、 オプティマイザのアップグレードを行った結果、一部機能のパフォーマンスが落ちてしまった・・・ といったような事も起こりえます。 Powered by WordPress with Lightning Theme & VK All in One Expansion Unit by Vektor,Inc. with句を複数宣言する方法 with句 を複数宣言する場合には先頭のselect文には with を記述しますが、 そのあとのselect文はカンマで区切って with句 の名前を直後に記述します。 sql> with test_with1 as ( 2 select * 3 from tt_売上 4 where 担当者コード in (1, 2) 5 ) 6 , test_with2 as ( 7 select * 8 from tt_売上 … SQLのWITH句って利用していますか?私の周りでは意外と使ったことがないという方がいらっしゃいます。, 今回はWITH句を利用して複雑なサブクエリをシンプルにして利用する方法を紹介します。, 従業員の交通費申請を保持する[申請テーブル]があって、その申請が今どういう状態かを表す「ステータス」という項目があります。, もう一つ従業員の情報を保持する[従業員テーブル]があって、その従業員がどの支社に所属しているかを表す「支社コード」という項目があります。(他にも氏名等の項目を持ちますが、今回は説明を単純にするため省略します), まずWITH句を利用して[申請テーブル]と[従業員テーブル]を結合したものを[base]とし、, その[base]からそれぞれ従業員数、申請数、承認数をカウントし最後にひとまとめにして取得しています。, まずWITH句の最初に、以下の結果を返す[base]テーブルを作っているようなものです。, 次に[base]テーブルから従業員数をカウントした[jugyoin]テーブルを用意し、, 同じく[base]テーブルからステータスが「1:申請中」のものをカウントして[shinsei]テーブルとし、, 続いて[base]テーブルからステータスが「2:承認済」のものをカウントして[shonin]テーブルとし、, [base]を再利用することで、同じサブクエリが何回も出てくるのを防ぎ読みやすくなっていると思います。, 今回はサンプル用なので、そんなに複雑なWITH句になっていませんが、読みやすくなる効果は分かってもらえると思います。, 普通にサブクエリだけをつなげるのと、WITH句を利用したときのパフォーマンスを比較したサイトもありますね。, IT業界に入ってSQLの学習で初めてサブクエリというもの知ったとき便利なものだなと感じました。, ただし、そこで満足してSQLの学習が止まっていると、WITH句に出会うことがないのかもしれませんね。, 空きメモリが足りているのに PHP Fatal error: Out of memory が発生する原因と解決方法.