今回のOracle Database Technology Nightでは、簡単な実行計画しか見れない方や見るのを諦めている方などを対象に、SQLチューニングの基本となる実効計画について出力方法、見方、注意点などを簡単に解説します。
1. はじめに 仕事の都合で DB/SQL の性能問題を調査する機会が少なくありませんが(決してメインの仕事ではないですが)、その中でよく出くわす問題の1つに「ぐるぐるSQL」(もしくは「ぐるぐる系」)といわれる、ループで大量の SQL 文を呼び出しているものがあります。 感覚ですが、私の周りでは OLTP 系システムの DB/SQL の性能問題の原因の割合は以下のように感じています。 30%:ぐるぐる SQL 20%:SQL 文の書き方が不適切 15%:索引がない or 不適切 15%:パーズが遅い 10%:データモデルがおかしい 10%:その他 (大昔は2番目 / 3番目がほとんどだったのですが、最近はなぜがぐるぐる SQL が多い…) ぐるぐる SQL の実装では、ネットワーク通信や、アプリ側のクエリ生成 / 結果データ構築、DB 側のクエリ受信 / 結果送信といった、処理の本質的で
カーディナリティとは テーブルにカラムがあるとして、カラムに格納されているデータの種類がどのくらいあるのか(カラムの値の種類の絶対値)を、カーディナリティという。 具体例 カーディナリティが低い場合 例えば性別なら、男と女の二種類である。 カラムのデータの種類が、テーブルのレコード数に比べて二種類と少ない。このことを カーディナリティが低い という。 カーディナリティが高い場合 一方顧客番号ならたくさんの種類(番号)が存在することになる。 カラムのデータの種類が、テーブルのレコード数に比べて多い場合、 カーディナリティが高い という。 カーディナリティを踏まえたインデックスの張り方 基本的に、 カーディナリティの高い列に作成する 必要がある。 はじめに、カーディナリティは カラムの値の種類の絶対値と書いたが、先程の例で言うと性別のカーディナリティは2になる。他にも例えば1年間の日付なら1〜
MySQLのSELECT時にORDER BYを使用した時のソートの話 テーブルにINDEXが貼られている事が前提ですが、 例えば3テーブルを結合し、ソートをかける時などに、 全てのテーブルの結合を行った後にマスターとなるテーブルで並び替えると、 Using filesortが発生し、SELECTの実行が遅くなる場合があります。 回避方法として、カラムの表示用のマスターテーブルと、ソート用に使うマスターテーブル(別名付け)を用意し 用途を分けたSELECT文にするなどがあります。 sample.sql SELECT tbl1.col1, tbl2.col2, tbl3.col3 FROM tbl1,tbl2,tbl3 INNER JOIN tbl1 AS tbl4 ON tbl1.col1 = tbl4.col1 WHERE tbl1.col1 = tbl2.col1 AND tbl2.co
最近、寒暖の差が激しいですがみなさん体調は崩されていないでしょうか? こんにちわ。モニプラ for Facebookを担当しています高橋です。 サービス開始当初は問題なかったものの稼働が高くなりデータ量が多くなって クエリのパフォーマンスが悪化すること…よくありますよね? 今回はクエリチューニングの基本的な手順とケース別に解決方法を解説したいと思います。 クエリチューニングの手順 1.スロークエリログで問題のクエリをあぶり出す まずはどのクエリが問題なのか特定する必要があります。 アプリケーション側でクエリの実行時間を測定し自前でログを出力しておくというのも手ですが、 お手軽にMySQLの設定で一定時間以上掛かったクエリをログに出力しておくことができます。 スロー クエリ ログ(MySQL 5.1 リファレンスマニュアル) mysqldを–log-slow-queriesオプションつきで起
Amazon RDS Performance Insights はデータベースパフォーマンスのチューニングとモニタリングを行う機能で、データベースの負荷をすばやく評価し、いつどこに措置を講じたらよいかを判断するのに役立ちます。Performance Insights のダッシュボードはわかりやすく、データベースの負荷が可視化されるため、専門的知識のないユーザーでもパフォーマンスの問題を検出できます。 Performance Insights はアプリケーションのパフォーマンスに影響しない軽量のデータ収集方法を使用し、負荷を発生させている SQL ステートメントとその理由を簡単に調べられるようにします。設定もメンテナンスも不要で、現在は Amazon Aurora (PostgreSQL および MySQL 互換版) と Amazon RDS for PostgreSQL、MySQL、Mar
We looked previously at getting set up with GraphQL on Rails. We defined some queries, some mutations, and had a good time doing so! But what if I told you that with only a few hundred records in the database, it's possible to write a query that brings our server grinding to a halt? In this article, we'll look at three ways to avoid performance issues with GraphQL in your Rails app, and then at a
すでにOracle シングル・サインオンのアカウントをお持ちのお客様は、上記のログイン をクリックしてお進みください。 登録がお済みではなく、アカウントをお持ちでないお客様は、Sign Up より登録画面へお進みください。
よくMySQLはサブクエリが弱いと言われるが、これは本当だろうか?半分は本当で半分は嘘である。MySQLのサブクエリだってなんでもかんでも遅いわけではない。落とし穴をしっかり避け、使いどころを間違えなければサブクエリも高速に実行できるのである。今日はMySQLがどんな風にサブクエリを実行し、どのような場合に遅いのかということについて説明しよう。 EXPLAINで実行計画を調べた際に、select_typeにはクエリの種類が表示されるのだが、代表的なサブクエリには次の3つのパターンがある。 SUBQUERY DEPENDENT SUBQUERY DERIVED 結論から言おう。遅いのは2番目、DEPENDENT SUBQUERYである。DEPENDENT SUBQUERYとはいわゆる相関サブクエリに相当するもので、サブクエリにおいて外部クエリのカラムを参照しているサブクエリのことである。そし
If you’re interested in translating or adapting this post, please contact us first. Let’s talk about the N+1 problem in Rails. We will go through a short intro for beginners, speak of the ways to tame the problem (specifically, using the bullet gem), ActiveSupport instrumentation, and introduce the rspec-sqlimit gem. The Hydra In the Rails ecosystem, every developer knows about the so called N+1 q
やりたいこと こんな感じで、MySQLでボトルネックになりそうなslowクエリをslackに通知させて、 継続的に、クエリチューニングできるようにしたい。 なので、Mysqlで出力されたスロークエリログをfluentdで取得し、 そのクエリに対して、explainを実行させて、クエリの内容と一緒に、 explainの結果をslackに通知できるようにする。 1. 準備 slackの投稿先webhookURLを用意する IncomingWebHookのキー発行は以下から取得する https://xxx.slack.com/services/new 参考URL: http://qiita.com/vmmhypervisor/items/18c99624a84df8b31008 2. 環境構築 fluentd インストール
数年やってないと記憶の彼方に飛んでいきそうだったので、MySQLのクエリ改善方法のテンプレを自分用に明記。 スロークエリを除去する事。 初めはとにかく観察。スロークエリを出力させて、観察する。 indexが効かないクエリを排除する。 indexが予期できない条件分岐によるクエリを廃止する。 場合によってはソートをさせない。コード側でソートさせる。 JOINをわざとさせないのも一つの手。後にDB分離レベルのシャーディング等が発生する可能性のあるようなシステムでは、JOIN禁止にする事は決して間違ってはいない。 indexを必ず効かせる レコード数に応じて、割当たるindexが異なることがあるので、必ず同じデータ数か実際の運用環境で検証すること。 但し、indexを増やし過ぎると、挿入時に更新対象が増えるため、必要最低限にすること。 explain してindexを確認する 特に注目しなければ
"Query rate" redirects here. Not to be confused with Query throughput. This article needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. Find sources: "Queries per second" – news · newspapers · books · scholar · JSTOR (August 2020) (Learn how and when to remove this template message)
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く