アクセスプラン(実行計画)の読み方入門

24,989 views

Published on

第175回 CLUB DB2「アクセスプラン(実行計画)の読み方入門」の資料です。

https://www.ibm.com/developerworks/community/wikis/home?lang=ja#!/wiki/ClubDB2/page/%E7%AC%AC175%E5%9B%9E

2 Comments
20 Likes
Statistics
Notes
No Downloads
Views
Total views
24,989
On SlideShare
0
From Embeds
0
Number of Embeds
5,388
Actions
Shares
0
Downloads
170
Comments
2
Likes
20
Embeds 0
No embeds

No notes for slide

アクセスプラン(実行計画)の読み方入門

  1. 1. アクセスプラン(実行計画)の アクセスプラン(実行計画)の 読み方入門 CLUB DB2 第175回 2014年1月31日 下佐粉 昭 (しもさこ あきら) rev. 1.1
  2. 2. 自己紹介 下佐粉 昭 ( しもさこ あきら ) 和歌山県生まれ 2001年 IBMに中途入社 以来、DB2関連の仕事多し 現在は金融系のお客様担当SE ■書籍 「即戦力のDB2管理術」 管理術」 「即戦力の http://db2.jugem.cc/?eid=2341 (書籍紹介) 「XML-DB開発 実技コース」(共著) 開発 逆引きリファレンス」(共著) 「DB2 逆引きリファレンス」(共著 ■オンライン Twitter - @simosako http://twitter.com/simosako Unofficial DB2 Blog 絶版になったので本の内容を全てWEB で公開しています http://db2watch.com/ http://db2.jugem.cc/ 2
  3. 3. 今日の内容 アクセスプラン(実行計画)って聞いた事ありますよね? でもなんかすごく難しそう… どうやって、見ればよいのか分からない そもそも、なぜそんなものが必要なの? パフォーマンス問題の解決には、アクセスプランが必須 用語さえ理解すれば、すぐ読めるようになります なぜ必要なのかという「理由」と 最低限必要となる「読み方」 最低限必要となる「読み方」を理解しましょう 3
  4. 4. 内容 アクセスプラン(実行計画)とデータベース アクセスプランとは? なぜ必要なのか アクセスプラン決定に影響を与える要因 表スキャンとインデックス・スキャン DB2のアクセスプラン:基礎 統計情報とアクセスプラン DB2でアクセスプランを取得するには アクセスプランの基本的な読み方 フィルター・ファクター ジョイン・メソッド この資料の記述は、DB2 10.5を対象にしています 4
  5. 5. アクセスプラン(実行計画)と データベース
  6. 6. そもそもアクセスプラン(実行計画)って? 取り出したいデータは一つ、でも方法は色々ある 行きたい場所は一つ、でも方法は色々ある… 一番早く着く のはどれ? (人が決める) 6 目的地
  7. 7. ではデータベースの場合は? アクセスプラン(方法)は、データベースが決定する ユーザが決めない ユーザが決めるのは、欲しいデータ(SQL)だけ 全ての情報を知っているのはデータベース ⇒最も速い方法を、自動的に決定してくれる 具体的に理解するために、まず基本的なアクセスプランである 表スキャン インデックス・スキャン の違いを理解しましょう 7
  8. 8. 表スキャン(テーブル・スキャン) 表全体を順に読んでいって、必要なデータを発見する 例)SELECT * FROM MEMBER WHERE JOB='ANALYST' 順に読んで、データを探す JOB列が'ANALYST'の 行を読み出すSQL レコードIDは内部管理用 (ユーザには見えない) レコードID ID NAME JOB 0001 1 CHRISTINE HAAS PRES 0002 2 MICHAEL THOMPSON MANAGER 0003 3 SALLY KWAN MANAGER : : : : 0011 11 DELORES QUINTANA ANALYST 0012 12 HEATHER NICHOLLS ANALYST : 8 : : :
  9. 9. インデックス・スキャン(索引スキャン) インデックスを読んで⇒表からデータを取り出す インデックスは目次のようなもの:対象のレコードIDを記録している > CREATE INDEX IDX_JOB ON MEMBER(JOB) MEMBER(JOB) 先にインデックスを参照することで必要なデータだけを読む 先にインデックスを参照することで必要なデータだけを読む インデックス IDX_JOB ANALYST SELECT * FROM MEMBER WHERE JOB='ANALYST' レコードID ID NAME JOB 0001 1 CHRISTINE HAAS PRES 0002 2 MICHAEL THOMPSON MANAGER 0003 3 SALLY KWAN MANAGER {0011} {0012} MANAGER {0002} : : : : {0003} 0011 11 DELORES QUINTANA ANALYST 0012 12 HEATHER NICHOLLS ANALYST {0004} PRES : {0001} 9 : : :
  10. 10. アクセスプランを人が決定するのは困難 (1/2) 最適なアクセスプランを選択するには? 平均処理時間 表スキャン 0 10 取得したいデータ量 [%] 100
  11. 11. アクセスプランを人が決定するのは困難 (2/2) 最適なアクセスプランは常に変わる 平均処理時間 インデックス・スキャン 表スキャン ここで、インデックス・スキャンから表ス キャンに切り替わるのが理想 0 11 取得したいデータ量 [%] 100
  12. 12. アクセスプラン決定に影響を与える要素 データサイズ SELECT * FROM 社員表 WHERE 職位='一般社員' SELECT * アンサーセットの大きさ 表の大きさ データには偏り 偏りがあるかもしれない 偏り 使用可能なインデックスの有無 どれぐらい絞り込めるか? 絞り込めるか? その他リソースの影響 バッファー(メモリー)の大きさ CPU処理速度 ディスク速度 12 FROM 社員表 WHERE 職位='部長' アンサーセット の量は同じ??
  13. 13. ではなぜ、アクセスプランをユーザが意 識する必要があるの? 理由:データベースは、与えられた材料以上のことは 出来ないので… SQLが遅い理由は?どこで遅いのか 作成したインデックスが使われているか? バグ? ユーザが確認するためにアクセスプランを見る機能が 必要 豆知識: ⇒EXPLAIN(エクスプレイン) EXPLAINという単語は、 という単語は、DB2独 という単語は、 独 自の単語ではなく、DBMSで広く 自の単語ではなく、 で広く 一般的に使われている用語です 13
  14. 14. ここまでのまとめ アクセスプラン=データを「どの方法で取り出すか」 アクセスプランを見る手段や結果=EXPLAIN 最適なアクセスプランを選択するには… データの量 データの偏り インデックスなどの有無 ディスク配置 使用メモリ量 非常に複雑 多くの要因 : 人間には無理なのでコンピュータに判断させるべき コンピュータの判断を確認するためにEXPLAINを使用 14
  15. 15. <演習タイム> 別紙の問題用紙を使ってグループ演習をしてみま しょう! 数人でグループになりましょう 1. 最初にそれぞれ自己紹介 (一人1分ぐらい) 2. みんなで回答を考えてください • • 問題1~5を解いてみて下さい。理由も考えて下さい! 時間があまったグループは問題6~7にトライしてください WEB中継で参加の方もぜひ各自で演習をしてみてください 問題用紙は以下からダウンロード可能です 問題用紙 http://j.mp/18VqmZv (CLUB DB2ホームページ) 15
  16. 16. DB2のアクセスプラン:基礎
  17. 17. アクセスプランと統計情報 DB2は統計情報を元に最適なアクセス・プランを作成する 統計情報が古いと、非効率的なアクセス・プランを作成してしまう 統計情報の更新には、RUNSTATSコマンドを使用する ⇒RUNSTATSで統計情報を最新に保つことが重要 オプティマイザー 照会書き直し 照会 グラフ・ モデル システム・カタログ 代替案の作成 統計情報 実行コスト見積もり SQLコンパイラー SQLコンパイラー RUNSTATS RUNSTATS → → → → インデックス SQL実行 アクセス プラン テーブル データベース 17 SQL
  18. 18. 統計情報の自動更新 自動RUNSTATS(V9.1以降) 2時間に1度表の更新情報をチェックし、更新が必要となった表に RUNSTATSが実行される 決められた「作業時間枠」の中で実行させる事も可能 DB CFGのAUTO_RUNSTATS (デフォルトでON) 上位パラメタのAUTO_TBL_MAINTとAUTO_MAINTもONである必要があります リアルタイム統計機能(V9.5以降) クエリーを実行した瞬間にその表にRUNSTATSが必要か不要かを判断 必要であれば先にRUNSTATSを実行してからクエリーを実行する 統計情報が常に最新の状態に保たれる リアルタイムで統計情報を取得するには時間がかかり過ぎる表に関しては、既存の情 報から統計情報を擬似的に作成して実行 DB CFGのAUTO_STMT_STATS (デフォルトでON) 18
  19. 19. EXPLAIN機能の使い方 事前準備: 情報を格納するEXPLAIN表をDBに作成しておく必要がある 方法1)sqllib/misc/EXPLAIN.DDLを実行して作成する 方法1) > db2 -tvf .../sqllib/misc/EXPLAIN.DDL 方法2) ストアドプロシージャを実行して作成する(DB2 9.5以降) > db2 "CALL SYSPROC.SYSINSTALLOBJECTS('EXPLAIN','C',NULL,CURRENT SCHEMA)" 1. EXPLAINモードを有効にする > SET CURRENT EXPLAIN MODE EXPLAIN 2. 3. SQLを実行すると、そのアクセスプランがEXPLAIN表に格納さ れる EXPLAINモードを元に戻す > SET CURRENT EXPLAIN MODE NO 4. 19 なんらかの方法でEXPLAIN表からデータを取得する 参考)SYSINSTALLOBJECTSプロシージャ http://pic.dhe.ibm.com/infocenter/db2luw/v10r5/topic/com.ibm.db2.luw.sql.rtn.doc/doc/r0011876.html
  20. 20. DB2のEXPLAIN閲覧ユーティリティ db2exfmt もっとも詳細な情報 もっとも詳細な情報が得られる 詳細な情報 これがお勧めです(次ページに詳細) db2expln 事前準備無しですぐ使える 例) >db2expln -d DB名 -t -g -q "SQL文" >db2expln -d DB名 -t -g -f ファイル DataStudio (GUI)内蔵のVisual Explain GUIで操作可能 20
  21. 21. db2exfmtでアクセスプランを取得する方法 手順 1. 2. set current explain mode explain でEXPLAIN取得状態に 任意のSQLを流す SQLは実際には実行されずに、 アクセスプラン情報がEXPLAIN表に書き出される 3. 4. set current explain mode no で元に戻す db2exfmtコマンドで、必要なEXPLAIN情報を取り出す 例) db2 connect to sample db2 set current explain mode explain db2 "任意のSQL" db2 set current explain mode no db2exfmt -1 -d SAMPLE -o myexplain.txt 標準的なオプションで直近(最新) のEXPLAIN結果を出力 EXPLAIN表へアクセスプランの書き出し 表へアクセスプランの書き出し 表へアクセスプラン 出力ファイル名 データーベース名 ※表や列名に日本語を使っている場合は、db2exfmtのオプションに-no_map_char が必要です 21 (参照)db2exfmtコマンド http://pic.dhe.ibm.com/infocenter/db2luw/v10r5/topic/com.ibm.db2.luw.admin.cmd.doc/doc/r0002353.html
  22. 22. アクセスプランの基 本的な読み方 例)SELECT * FROM MEMBER WHERE JOB IN ('MANAGER','OPERATOR','SALES') ()内はオペレーション番号 下から上へ読む 下から上へ どのオブジェクト(表やインデッ クス)を使っているか 表スキャンで13,312行 を戻している 演算子の種類と、戻す行数 戻す行数 演算子 コスト:304.324 演算子のコスト [timeron] コスト 時間ではない 累積値 DB2INST1.MEMBER 表にアクセス。この表は 43,008行を保持 (※「Q3」は自動的に付けら れた相関名) 22
  23. 23. Filter Factor(フィルター・ファクター)と見積り行数(1/3) SELECT * FROM MEMBER WHERE JOB<>'PRES' SELECT * FROM MEMBER WHERE JOB='PRES' 右と左の違いは? WHERE句の演算子の違い Filter Factorの違い Filter Factor: 0.875 Predicate Text: -------------(Q1.JOB <> 'PRES ') Filter Factor: 0.125 Predicate Text: -------------(Q1.JOB = 'PRES ') 23
  24. 24. Filter Factor(フィルター・ファクター)と見積り行数(2/3) 見積り行数は正しい? SELECT * FROM MEMBER Filter Factorは0.875なので37,632行返すと DB2は考えている WHERE JOB<>'PRES' 43008行 × 0.875 = 37,632行 Filter Factor: 0.875 Predicate Text: -------------(Q1.JOB <> 'PRES ') 実際は何行? db2> SELECT COUNT(*) FROM MEMBER WHERE JOB<>'PRES' 1 ----------41984 24
  25. 25. Filter Factor(フィルター・ファクター)と見積り行数(3/3) アクセスプランはあくまで「予想」 見積りと実際の間で「ずれ」がある可能性 データは常に変動しているのである程度のずれは問題無い 見積と実際が大きく異なる場合は統計情報を更新する 統計情報の更新方法 統計情報が古い場合 データが大量に変化した後にRUNSTATSを実行していない 場合、まずRUNSTATSを実行 分散統計を利用 RUNSTATS … WITH DISTRIBUTIONオプションで分散統 計を取得 (※オプションについては補足資料を参照) 分散(値のばらつき、偏り)も含めた統計情報を収集すること で精度を向上させる Filter Factor: 0.97619 RUNSTATS … WITH DISTRIBUTIONを指定して統 計情報を更新した直後のアクセスプランの例。偏りが 反映されて、より正確な見積りが実現できている Predicate Text: -------------(Q1.JOB <> 'PRES ') 25
  26. 26. 演算子の種類(抜粋) TBSCAN:表スキャン(Relation Scan, Table Scan) テーブルを直接読み取る IXSCAN:インデックス・スキャン(Index Scan) 最初にインデックスにアクセスする FETCH:フェッチ 特定のレコードID (RID)を使って、表から値を取り 出す RIDSCN:リッドスキャン レコードID(RID)の一覧を作成してI/Oサーバー (FETCH)に渡す SORT:ソート 与えられたデータを昇順、降順に並べ替える 重複をなくすためにも使用される +ジョインメソッド NLJOIN:ネステッド・ループ・ジョイン MSJOIN:マージ・スキャン・ジョイン HSJOIN:ハッシュ・ジョイン 26
  27. 27. ジョイン・メソッド ジョイン(JOIN、結合)とは (極論すれば)2つの表にあるそれぞれの行で、同じ列の値を持 つ組み合わせを全て見つける 組み合わせを全て見つける作業 組み合わせを全て見つける 3種のジョイン・メソッド NLJOIN:ネステッド・ループ・ジョイン MSJOIN:マージ・スキャン・ジョイン HSJOIN:ハッシュ・ジョイン ※この後のジョインの説明方法は、以下URLの「DB2 UDB アクセス・プラン速習」を連 載していたプロフェッサー奏太郎先生からアイデアを教えてもらったものです。 http://ibm.com/jp/software/data/developer/column/accessplan/ 27
  28. 28. NLJOIN:ネステッド・ループ・ジョイン [Q] 3枚のトランプが左にあり、2枚のトランプを右手にあって、右と左で 番号が同じものを選ぶ時、どうしますか? ⇒左の3枚をそれぞれ総当たりで右と比べて、3×2 = 6回の比較 2 2 2重のFORループのようなイメージ 片方の表が小さい場合に向く 4 小さいとオンメモリで処理可能 4 A A 少メモリ 枚数が多いと遅くなる 2 2 4 4 28
  29. 29. MSJOIN:マージ・スキャン・ジョイン [Q] 30枚のトランプが左に山積みで、20枚のトランプが右に山積みで、 右と左で番号が同じものを選ぶ時、どうしますか? 1. 左の30枚のトランプを、あらかじめ小さい順にソート 2. 右の20枚のトランプも、あらかじめ小さい順にソート 3. 比較して、同じか小さい値は捨てていく 3 4 比較(めくり)回数は左枚数+右枚数 = 50回 2 3 7 3 4 ソートが必要だが、枚数が多い場合にも速い 4 6 7 29
  30. 30. HSJOIN:ハッシュ・ジョイン [Q] 3000枚のはがき束と20枚のはがき束で郵便番号 桁が一致するも 郵便番号7桁 郵便番号 のを選ぶならどうしますか? 1. 郵便番号3桁で区分けする棚を用意する 2. 先に20枚のはがきを、全て郵便番号3桁の棚へ分ける 3. 次に3000枚のはがきの束を郵便番号3桁の棚へ振り分ける この時、先のはがきが入っていない棚には振り分けずに捨てる 4. それぞれの棚の中で、つき合わせをする(NLJOINなど) ハッシュ計算が高速なら、非常に速度が出る CPU負荷は高く、メモリ使用量も大きめ 1 2 7 1 2 7 1 1 1 1 1 2 7 1 2 7 2 1 1 1 1 1 1 1 2 7 30 3 3 3 3 1 1 1 1 127の棚 1 1 1 1 9 9 9 9 2 1 1 1 1 1 1 1 2 7 9 9 9 9 2 1 1 3 3 3 3 2 1 1 1 1 1 1 211の棚
  31. 31. まとめ アクセスプランは、パフォーマンス問題解決の肝 詳しく読めなくても、採取できるだけで違う DB2の「意図」を理解できるようになる 障害時の問題解析にも役立つ DB2固有の部分を理解しましょう RUNSTATSで統計情報を収集(最近は自動化) db2exfmtやVisual Explainでアクセスプランを確認 NLJOIN : 小さいジョイン向け MSJOIN , HSJOIN : 大きいジョイン向け 31
  32. 32. 参考資料 DB2 UDB アクセス・プラン速習(連載) 日本一(世界一かも)詳しいDB2のアクセスプラン解説 http://ibm.com/jp/software/data/developer/column/accessplan/ カンタン!DB2テクテク第1歩 基本機能編 EXPLAINやスナップショット・モニターの使い方がやさしく解説されています http://ibm.com/jp/software/data/developer/library/techdoc/kantandb2.html CLUB DB2 基礎編資料 運用管理編(バックアップ、表の再編成、統計情報の更新) http://www.slideshare.net/simosako/db2-13132216 簡単運用管理入門 (RUNSTATSの自動化と、オプションの設定) http://www.slideshare.net/simosako/club-db2-122-db2-11755316 DB2 Express-Cの導入方法解説(無料のDB2で試しましょう!) http://www.ibm.com/developerworks/jp/offers/db2express-c/installwin_v10/ (Windows用) http://www.ibm.com/developerworks/jp/offers/db2express-c/installlin_v10/ (Linux用) 32
  33. 33. 参考資料(マニュアル) DB2のオンラインドキュメント:インフォメーションセンター 常に更新されるので最新の情報が閲覧できます。検索機能付き DB2 10.5版 http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/index.jsp その他のバージョン、PDF版マニュアルなどは以下から http://www-01.ibm.com/support/docview.wss?uid=swg27009474 IBMソフトウェア、ハードウェア総合のマニュアルサイト「Knowledge Center」 (公開ベータテスト中) http://www.ibm.com/support/knowledgecenter/ 33
  34. 34. 補足資料
  35. 35. 【補足】RUNSTATSコマンド(統計情報の更新) RUNSTATSコマンドで統計情報を更新する 多くの場合、この 基本形でOK RUNSTATS ON TABLE スキーマ名.表名 RUNSTATS ON TABLE スキーマ名.表名 AND INDEXES ALL (※DB2 10.1からスキーマ名が省略可能になっています) RUNSTATS実行中でも表に読み書きアクセス可能 少し進んだ使い方 データに「偏り」がある場合、分散統計 を試してください。こちらもお勧め ①分散統計で収集する RUNSTATS ON TABLE スキーマ名.表名 WITH DISTRIBUTION RUNSTATS ON TABLE スキーマ名.表名 WITH DISTRIBUTION AND INDEXES ALL ②サンプリングでRUNSTATSの実行時間を短くする RUNSTATS ON TABLE SIM.DEPARTMENTS WITH DISTRIBTION TABLESAMPLE BERNOULLI (5) 35 表を5%サンプリングする例(大 規模環境用)
  36. 36. 【補足】分散統計とインデックス 表の分散統計 (WITH DISTRIBUTION) 表データに「偏り」があり、その表がパフォーマンス上重要な場合はRUNSTATS … WITH DISTRIBUTIONで表データの偏り(分散状況)を含めた統計情報を取得することで、より精度 の高いアクセスプランが作成可能になります 巨大な表で分散統計を取得すると、実行時間が長くなりすぎる場合があります。その場合は TABLESAMPLEオプションでサンプリングを設定することで時間を調整可能です インデックスの分散統計 RUNSTATSで"… AND DETAILED INDEXES ALL"を指定することで、インデックスの分散 統計を取得できますが、インデックスの分散統計を取得することでアクセスプランが改善出来 るケースは(表の分散統計と比較すると)少ない傾向にあります DB2 9.7までと10.1ではインデックスの分散統計の挙動が変更されています 9.7まで: デフォルトでインデックス全体の分散情報を取得。SAMPLED DETAILEDと指定すると、サン プリングを実施 10.1から:デフォルトでは、インデックスをサンプリングして部分的な分散統計を取得。UNSAMPLED DETAILEDと指定すると、サンプリングせずに全体の分散統計を取得 インデックスの分散統計取得の例) RUNSTATS ON TABLE スキーマ名.表名 WITH DISTRIBUTION AND SAMPLED DETAILED INDEXES ALL 36
  37. 37. 【補足】EXPLAINの演算子(主要なもの) ※ XQuery/XPath関連の演算子は除いています 37 EXPLAIN演算子の一覧はこちら http://pic.dhe.ibm.com/infocenter/db2luw/v10r5/topic/com.ibm.db2.luw.admin.explain.doc/doc/r0052023.html
  38. 38. 【補足】統計情報の移動 「開発環境で、アクセスプランを確認しながらSQLを開発したい … しかし開発環境ではサイズが大きいDBを作成できない」 ⇒統計情報が異なるため、同じアクセスプランにならない 同じアクセスプランにならない 表のデータ量が異なる バッファープールのサイズが異なる 統計情報も単なる表なので、本番環境から統計情報のデータをコピーす ることで、同じアクセスプランを生成できます。ただしバッファープールの大 きさがアクセスプランに大きな影響を与える場合があるため、それをごま かすためのdb2foptコマンドも用意されています db2look -m : 統計情報をコピーするDDLとINSERT文を生成 db2fopt : バッファープールサイズを「ごまかす」ためのコマンド 参照 「db2look を使用してのオプティマイザーのアクセス・プランの再作成」 http://ibm.com/developerworks/jp/data/library/techarticle/dm-0508kapoor/ 原文(英語) http://ibm.com/developerworks/db2/library/techarticle/dm-0508kapoor/ 38
  39. 39. 【補足】 db2batchでSQLの実行時間を測定する SQLの実行時間を測定する場合、端末からの速度測定は誤差が大きい ネットワーク経由でデータが転送される時間 端末画面に表示されるのに掛かる時間 などの誤差 ベンチマーク用ユーティリティー:db2batch ファイルに書かれたSQL(複数可)を実行する 誤差の少ない測定が可能 便利なオプション多数 (-o の後に指定) アンサーセットを出力しない(内部的にフェッチは行う) : r 0 EXPLAIN表にアクセスプランを格納する : e 2 SNAPSHOTを取得する: p 3 例)上記オプションを全て指定した例 db2batch -d sample -f file1.sql -o r 0 e 2 p 3 -r out1.txt データベース 39 SQLファイル名 オプション 出力ファイル
  40. 40. * タイム・スタンプ: Wed Jan 08 2014 20:17:58 JST 【補足】 db2batch 出力例(抜粋) --------------------------------------------* SQL ステートメント番号 1: SELECT * FROM MEMBER WHERE JOB IN ('MANAGER','OPERATOR') ; ID NAME JOB SALARY db2batchを実行した日時 を実行した日時 ----------- -------------------- -------- ----------- * 13312 行取り出され、0 行出力されました。 実行したSQLステートメント ステートメント 実行した * 経過時間: 0.037023 秒 データベース・マネージャー・スナップショット DB2 インスタンス内のメンバー数 = 1 データベース・マネージャー状況 = アクティブ 製品名 = DB2 v10.5.0.2 サービス・レベル = s131001 (IP23536) 実行時間 データベース名 = SAMPLE スナップショット・モニターからの出 力(左図はごく一部の ごく一部 力(左図はごく一部の抜粋) 読み取り行数 = 43008 書き込み行数 = 0 削除行数 = 0 更新行数 = 0 挿入行数 = 0 フェッチ行数 = 13312 バッファー・プール・データ論理読み取り = 244 バッファー・プール・データ物理読み取り = 1 * 合計項目数: 1 * 合計時間: 0.037023 秒 * 最小時間: 0.037023 秒 * 最大時間: 0.037023 秒 * 算術平均時間: 0.037023 秒 * 幾何平均時間: 0.037023 秒 40 その他、SQL実行時の情報 を多数得ることが出来ます

×