第3回 実行計画を見てSQLの構造を理解しよう | gihyo.jp
本記事は、『Software Design 2019年8月号』の第2特集「ゲームを題材に学ぶ 内部構造から理解するMySQL」をWeb掲載用に再編集したものです。 本記事のテーマを、より基本的なところから丁寧に解説した『SQLの苦手を克服する本 データの操作がイメージできれば誰でもできる』が2019年8月26日に発売されました。本記事と併せてご活用ください。 実行計画はSQL理解の大きな手がかり SQLはほかの手続き型言語と大幅に違います。そのため、ほかの手続き型言語と同じ感覚で使うと違和感が大きくなり、アレルギーのように嫌う人も出てきます。最近では、手続き型言語でORMを使うとSQLを意識しないでRDBMSをストレージのように扱うことが可能なため、SQLを理解する前にORMを使ってしまった人の中には、SQLをまったく理解していない人もいるようです。 しかし、正しい理解をしないまま使うとい
PostgreSQLが遅いときにcostとactualを確認しよう
OracleからPostgreSQLに移行する際に起きた問題。 PostgreSQLをインストールし、テーブルを作成してデータをインポートした。 が、検索が妙に遅い。 実行計画を見ると、インデックスを参照していない。 よくよく見てみたら、OracleにはあったインデックスをPostgreSQLには作成していなかった。 そりゃ参照しねえわと思い、インデックス張ってみた。 でも遅い…。確かに何個ものテーブルをJOINして、何十万行もの結果を返すとはいえ、30分はかかりすぎだろう。実用にはとても耐えられない。 explain analyzeで実行計画を見ると、costで予測する行数とactualで実際に取ってきた行数が異常に乖離している。これはおかしい。いくらなんでもおかしすぎる。costでは数千万、数億行取得すると予測しているのに、実際には数十万行程度しか取得していなかった。 もしかして、実行
PostgreSQLでSQLチューニングや障害状況調査に使ったクエリ達まとめ - $shibayu36->blog;
最近PostgreSQLでSQLチューニングや、DBが詰まった時の状況調査をいろいろやった。その時に便利だったクエリ達をまとめていく。PostgreSQLのバージョンは9.6系です。 SQLチューニングなどに便利だったクエリ達 それ以降に実行するSQLの実行時間を表示する。参考 https://morumoru00.wordpress.com/2011/05/08/postgresql-sql%E5%87%A6%E7%90%86%E6%99%82%E9%96%93%E3%82%92%E8%AA%BF%E3%81%B9%E3%82%8B%EF%BC%88timing/ \timing 実際にクエリを実行して実行計画や実行時間を表示する。クエリが実行されるので破壊的な操作も実行されてしまうことに注意。トランザクション張って最後にROLLBACKしましょう。参考 https://www.post
とあるクエリを2万倍速にした話 -データベースの気持ちになる- 前編 - dwango on GitHub
技術コミュニケーション室 OSSグループの髙﨑です。 当グループでは、マストドンというオープンソースの分散型マイクロブログについて、 弊社が運営するインスタンス「friends.nico」の運営、独自機能の開発、運用、ならびにそれらで得た知見を上流のプレーンなマストドンへcontributeするという業務を主に行っています。 本記事では、tableに適切なindexを張ることによってとあるスロークエリの速度改善を行った事例について、実際に上流へ行ったPullRequestをベースにお話させていただきます。 内容としては反面教師とするべき失敗例を伴った、非常に基礎的なPostgreSQLの実行計画の読み方ならびにクエリに合わせたindexの張り方です。 また、表題の2万倍速というのは改善前の最悪の場合比であり嘘ではないものの、通常問い合わせされる範囲の条件ではだいたい3〜30倍速であるという
Postgres Query Plan Visualization - tatiyants.com
After a recent stint in query optimization, I once again found myself wanting a better way to view query plans produced by EXPLAIN. So, I finally decided to do something about it and the result is Postgres EXPLAIN Visualizer (or Pev): Why Pev I wanted a tool that can make plans simple to understand and be visually pleasing. More specifically, I wanted: minimal visual noise insights high degree of
RailsエンジニアのためのSQLチューニング速習会 - Wantedly Engineer Blog
エンジニアの南直 @south37 です。 速習会の内容 2015年12月10日に、 Wantedly のオフィスにてRailsエンジニアのためのSQLチューニング速習会を開催しました！ RailsはRDBをたたく際に、Active Recordが最適化をよしなにやってくれるので複雑な処理やサービスの規模が小さい段階ではRDBに向き合う場面はすくないかと思います。しかし、サービス規模が大きくなってきたり、複雑な処理を行ったり、高速化に本気で向き合うときは、Active Recordの仮面をはぎとりSQLと向き合って細かなチューニングをおこなっていく必要があります。 今回の速習会では、SQLのチューニングの基礎として、SQLが実行されるときRDBの中ではなにがおきているか、Explainの読み方、Indexの張り方などをまとめています。 発表スライドはこちら Wantedly速習会 Want
カジュアルにMySQLスローログ可視化with Fluentd+Elasticsearch+Kibana - kikumotoのメモ帳
この記事は MySQL Casual Advent Calendar 2015 - Qiita Elasticsearch Advent Calendar 2015 - Qiita Hamee Advent Calendar 2015 - Qiita の第４日目です。 TL;DR 開発者の皆さんに、CasualにMySQLスローログを分析しもらうために、Fluentd + Elasticsearch + Kibana でMySQLスロークエリを下図のようにビジュアライズしました。（Kibana上で EXPLAIN の結果も確認できるようにしてあります） ついでに、以下の Fluentd の filter plugin を作成しました。 kikumoto/fluent-plugin-sql_fingerprint · GitHub kikumoto/fluent-plugin-mysql_e
MySQLのEXPLAINを徹底解説!!
以前、MySQLを高速化する10の方法という投稿で「EXPLAINの見方についてはいずれ解説しようと思う」と書いてしまったので、今日はその公約？を果たそうと思う。 MySQLのチューニングで最も大切なのは、クエリとスキーマの最適化である。スキーマの設計は一度決めてしまうとそのテーブルを利用する全てのクエリに影響してしまうためなかなか変更することは出来ないが、クエリはそのクエリだけを書き直せば良いので変更の敷居は低い。そして遅いクエリをなくすことは、性能を大幅に向上させるための最も有効な手段である。従って、アプリケーションの性能を向上させたいなら、まず最初にクエリのチューニングを検討するべきなのである。 最適化するべきクエリはスロークエリログやクエリアナライザで見付けられるが、ではそのようなクエリが見つかった場合にはどのように最適化すればいいのか？そのためにはまず現在どのようにクエリが実行さ
現代のMySQLはもう不要にINをEXISTSに書き換えない
漢(オトコ)のコンピュータ道: なぜMySQLのサブクエリは遅いのか。 この記事は 2009/3/25 に書かれたもののようである。 2009年3月といえばMySQL 5.1がGAになってわずか半年、MySQL 6.0.10-alphaがリリースされた頃で、MariaDBもまだ姿を見せていない頃だ。 時は流れて2015年、MySQL 5.6がGAになって早2年半、5.7のGAﾏﾀﾞｧ-? (･∀･ )っ/凵⌒☆ﾁﾝﾁﾝ な頃なので、もういい加減誰か言ってくれてもいいんじゃないかと思う。 もうMySQL(5.6)は不要にINをEXISTSに書き換えたりしないんだよって mysql51> EXPLAIN SELECT * FROM Country WHERE Continent = 'Asia' AND Code IN -> (SELECT CountryCode FROM City WHER
MySQLインデックスの基礎 その2 : 2つのクエリの違いとオプティマイザの判断 | Yakst
MySQLのインデックスを効果的に使う方法の第2弾。よく似た2つのクエリなのに、実際にはインデックスの使い方がそれぞれ異なることを通じて、オプティマイザがどのようにクエリの実行計画を立案するのか、そしてその結果どうインデックスが使われるのかを解説する。 前の記事では、ひとつのテーブルに対する様々なクエリを対象にして、インデックスのデザイン方法について議論しました。この記事ではより実世界に即した問題解決の例として、よく似ているにも関わらず、ひとつは適したインデックスを使い、もうひとつはフルテーブルスキャンをしてしまうという、2つのクエリを取り上げます。動作の違いはバグなのでしょうか？それとも想定された動きなのでしょうか？続きを読んでみてください！ 対象のクエリ2つ # Q1 mysql> explain select col1, col2 from t where ts >= '2015-0
mongodbのexplainを使って遅いクエリを調査してみてからのindex貼るメモ - tweeeetyのぶろぐ的めも
はじめに mongodb×phpでいろいろ集計しているのですがphpにtimeoutでexception吐かれちゃいました的なときの 簡単な調査と対応メモに合わせてindexを貼るのもメモっておきます。 吐かれたエラーはこんな感じ Fatal error: Uncaught exception \'MongoCursorTimeoutException\' with message \'10.2.xx.xx:27017: Read timed out after reading 0 bytes, waited for 30.000000 seconds\' in ・・・省略 まずはexplainの簡単な説明から クエリの調査ってことで鉄板のexplainですがこんな感じで使います db.collection.find().explain() 出力される結果はjson形式ですが各keyの意味
『[MongoDB]実行計画 $explain』
MongoDBもSQLと同じようにオプティマイザが実行計画を作っていて、 その実行計画を元にクエリを実行しています。 実行計画を確認するには、 >db.hoge.find().explain(); { "cursor" : "BasicCursor", "nscanned" : 4, "nscannedObjects" : 4, "n" : 4, "millis" : 0, "nYields" : 0, "nChunkSkips" : 0, "isMultiKey" : false, "indexOnly" : false, "indexBounds" : { } } みたいな。 上記だと全件取得なのでindexが使われておらず、 "cursor" : "BasicCursor" になっています。 とはいえ4件しかないからめちゃくちゃ速い("millis" : 0)ですが。 >db.hog
![『[MongoDB]実行計画 $explain』](https://cdn-ak-scissors.b.st-hatena.com/image/square/b2a7e2a6dbb2d0fe1a99db32e657fe50d13b9c67/height=288;version=1;width=512/https%3A%2F%2Fstat.profile.ameba.jp%2Fprofile_images%2F20141009%2F17%2Fca%2FmV%2Fg%2Fo014001401412842974962.gif)
YAPC::Asia Tokyo 2014でMySQLのWHERE狙いのキーとORDER BY狙いのキーの話をします
YAPC::Asia Tokyo 2014に応募していたトークを採択していただきました :) WHERE狙いのキー、ORDER BY狙いのキー - YAPC::Asia Tokyo 2014 たくさんの人に応援していただいていて、本当に感謝しております :) Talks Social Ranking - YAPC::Asia Tokyo 2014 WHERE狙いって何よとかORDER BY狙いってしゃらっと言ってますが、このへんはフィーリングで呼んでいるだけの造語です。MySQLに詳しい方にはなんとなーく伝わるんじゃないかなと期待していますが、どちらかというと「なんだよそれ造語かよ道理で聞いたこともない」って方に聞いていただきたいなぁと思っていたりします。 たとえば、EXPLAIN(目XPLAINでも可)でtype: ALLになるような(=テーブルスキャンの)クエリーってヤバそうじゃないで
PostgreSQLの実行計画の読み方 - おぼえがき
Explain Explainはプランナによって決定された「最良の」実行計画を表示する。 クエリを実行するための個々のステップを表示する。 DMLコマンドに対してのみ使用できる。 レコードセットのカラム数、行数およびコストを表示する。 数値は推測されたものであり、実際のコストをみるにはEXPLAIN ANARYZEを使う必要がある。 Explain Planの実行例 =# EXPLAIN ANALYZE SELECT oid FROM pg_proc; QUERY PLAN ------------------------------------------ Seq Scan on pg_proc (cost=0.00..87.47 rows=1747 width=4) (actual time=0.077..17.082 rows=1747 loops=1) Total runtime:
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
What's New in MySQL 5.7 Optimizer @MySQL User Conference Tokyo 2015
PostgreSQLクエリ実行の基礎知識 ～Explainを読み解こう～
PostgreSQL の auto_explain モジュールを使ってみた | はったりエンジニアの備忘録
Level up your MySQL query tuning