型キャストの場所のせいで、秒で終わっていたクエリに1時間超かかるようになってしまった話 - SmartHR Tech Blog
SmartHRで届出書類という機能を担当しているプロダクトエンジニアのsato-sと申します。 今日は、以前私が調査にとても苦労したパフォーマンス上の問題の話を紹介したいと思います。 TL;DR PostgreSQLのアップグレードを実施した アップグレード後、今までは問題のなかった特定のクエリの実行に1時間超かかり、DBのCPU使用率がピッタリ100%に張り付くようになった 色々調査した結果、PostgreSQL上の型キャストの場所のせいで、良くないクエリプランが選択されることが原因だった 型キャストの場所には気をつけよう PostgreSQLのアップグレードと挫折 SmartHRでは基本的にWebアプリケーションのデータベースとしてGoogle CloudのCloudSQLによって提供されるPostgreSQLを利用しています。 私の担当している届出書類機能では、利用中のPostgre
原因不明だったRDS負荷のスパイクを改善できた話 - Qiita
概要 当時数ヶ月間誰も原因がわからなかった一時的にRDSの負荷（CPU使用率）がスパイクする現象の原因を調査できる環境を整えて、原因分析〜改善まで実施したときの話です。 1つ1つの取り組み自体は大きなことはやっていませんが、一連の動きで得られたものも多かったのでアウトプットしようと思い記事にまとめました。 取り組んだ課題 原因を特定するためのツールがない そもそも何が原因でRDSのCPU負荷が高まっているのかを調べるための情報がCPU使用率以外に全くない状況でした。 そこでRDSの負荷原因を探る方法を調べると、Performance InsightsやCloudWatch Logsへのスロークエリログ出力を使う記事をいくつか見つけたのでこの2つについて調べることにしました。 Performance Insights データベース負荷をSQLなどの単位で時系列で可視化したり、トップSQLやD
PostgreSQL チューニングよもやま話 - エムスリーテックブログ
【Unit4 ブログリレー3日目】 こんにちは，エムスリーエンジニアリンググループの榎田です．数学とテレビゲームが好きです． 今回は，Unit4 で運用している "Docpedia" というサービスで実施した SQL チューニングの実例を2つご紹介します．普段の私が意識していなかった， RDBMS の内部機構に関する話が登場して面白かったので，今回の記事を書きました． なお，本稿で扱う議論はすべて PostgreSQL 11.x 以上を対象としており，特にその他の RDBMS で同様の動作をするかは確認していません．定性的な挙動に共通するものはあるかもしれませんが，ここで述べた話はそのままは通らないであろうことをお断りさせてください*1． プロダクトについて index なしで意外と耐えたが，耐えきれなかった話 実際の SQL とテーブル定義 原因の分析 対応策 SELECT DISTIN
MySQLでIN句の中に大量の値の入ったクエリがフルスキャンを起こす話 - freee Developers Hub
こんにちは、freee Developers Advent Calendar 2021、19日目のid:shallow1729です。昨日はtdtdsさんで【マジで】サイバー演習シナリオの作り方【怖い】でした！障害訓練後に攻撃方法を解説された時はリアリティの高さに驚きました。 僕はMySQLを使っていて発生した不思議な挙動の調査の話をしようと思います。 今回問題となったクエリ 今回話題にするクエリは以下のようなシンプルなものです。 SELECT * FROM hoge WHERE id IN (...) MySQLのパラメーター次第ですが、デフォルトの設定だとこのIN句の中の値の数が数万になると適切なインデックスが用意されていてもフルスキャンが発生する事がありました。このクエリがテーブルのほとんどのレコードを網羅するような場合や高速でレコードを大量にinsertして統計情報が追いつかないケー
How to interpret PostgreSQL EXPLAIN ANALYZE output
UPDATED July 2023: EXPLAIN ANALYZE is the key to optimizing SQL statements in PostgreSQL. This article does not attempt to explain everything there is to it. Rather, I want to give you a brief introduction, explain what to look for and show you some helpful tools to visualize the output. Also, I want to call your attention to a new patch I wrote which has been included in PostgreSQL 16, EXPLAIN GE
SQLが重いときに見るお気軽チューニング方法
SQLのチューニング方法 昔Qiitaで書いたものをzennにうつして、若干の修正、追加をしてみました。 ORACLEでの経験を元に書いていますがコストベースのリレーショナルデータべースなら大体共通の考え方だと思うので他にも使えると思います。 SQLのチューニングといえば比較的容易に済むインデックスをとりあえず作成する。といった対応を取られがちですが、数万レコード程度でのデータ量ではあまり効き目がなく（自分の経験則）、どちらかといえば、結合順が大幅に狂ってたりすることが原因のことが多かったりします。よって本当にインデックスがないことが原因なのか？を熟考する必要があります。（例えばID以外のフラグとかコードに単項目indexを貼ってるのもみたことがあります。怖いけど実話） また、インデックスを作りすぎるとオプティマイザが狂いやすくなって他のSQLにも悪影響を及ぼしたりするので結構熟慮して追加
第3回 実行計画を見てSQLの構造を理解しよう | gihyo.jp
本記事は、『Software Design 2019年8月号』の第2特集「ゲームを題材に学ぶ 内部構造から理解するMySQL」をWeb掲載用に再編集したものです。 本記事のテーマを、より基本的なところから丁寧に解説した『SQLの苦手を克服する本 データの操作がイメージできれば誰でもできる』が2019年8月26日に発売されました。本記事と併せてご活用ください。 実行計画はSQL理解の大きな手がかり SQLはほかの手続き型言語と大幅に違います。そのため、ほかの手続き型言語と同じ感覚で使うと違和感が大きくなり、アレルギーのように嫌う人も出てきます。最近では、手続き型言語でORMを使うとSQLを意識しないでRDBMSをストレージのように扱うことが可能なため、SQLを理解する前にORMを使ってしまった人の中には、SQLをまったく理解していない人もいるようです。 しかし、正しい理解をしないまま使うとい
Presto | Paper
Presto: SQL on Everything IEEE International Conference on Data Engineering (ICDE) Raghav Sethi, Martin Traverso, Dain Sundstrom, David Phillips, Wenlei Xie, Yutian Sun, Nezih Yigitbasi, Haozhun Jin, Eric Hwang, Nileema Shingte, Christopher Berner Abstract Presto is an open source distributed query engine that supports much of the SQL analytics workload at Facebook. Presto is designed to be adapti
Apache Sparkコミッターが教える、Spark SQLの詳しい仕組みとパフォーマンスチューニング Part2
2019年3月19日、Data Engineering Meetupが主催するイベント「Data Engineering Meetup #1」が開催されました。データの収集や管理、処理、可視化など、データエンジニアリングに関する技術の情報を共有する本イベント。データエンジニアリングの最前線で活躍するエンジニアたちが集い、自身の知見を共有します。プレゼンテーション「Deep Dive into Spark SQL with Advanced Performance Tuning」に登壇したのは、Databricks Inc.の上新卓也氏。講演資料はこちら Optimizer 上新卓也氏：これでLogical Planにキャッシュを使うプランが含まれてきたので、その次の処理としてはOptimizerですね。 これは今までプランの書き換えなどはやってこなかったんですが、ここからプランをガシガシと
Performance Tuning PostgreSQL
Introduction PostgreSQL is the most advanced and flexible Open Source SQL database today. With this power and flexibility comes a problem. How do the PostgreSQL developers tune the default configuration for everyone? Unfortunately the answer is they can't. The problem is that every database is not only different in its design, but also its requirements. Some systems are used to log mountains of da
RDB - 実例で学ぶ、JOIN (NLJ) が遅くなる理屈と対処法 - Qiita
"Nested Loop Joinしか取り上げて無いのにタイトルが大きすぎないか" と指摘を頂いたので、タイトルを修正しました。Merge JoinとHash Joinのことはまた今度書こうと思います。 「JOINは遅い」とよく言われます。特にRDBを使い始めて間がない内にそういう言説に触れた結果「JOIN=悪」という認識で固定化されてしまっている人も多いように感じています。 たしかに、JOINを含むようなSELECT文は、含まないものに比べて重たくなる傾向があることは事実です。また、本質的に問い合わせたい内容が複雑で、対処することが難しいものも存在します。しかし、RDBの中で一体どういうことが起きているのかを知り、それに基いて対処すれば高速化できることも少なくないと考えています。 本稿では、JOINの内部動作を解説した上で、Webサービスを作っているとよく出てくるJOIN SQLを例題に
開発者のためのSQLパフォーマンスの全て
前書き - インデックスの作成はなぜ開発者のタスクなのか インデックスの 内部構造 - インデックスは何に似ているか インデックス リーフノード - 二重連結リスト 検索 ツリー(Bツリー) - バランス木 遅いインデックス パートI - インデックスを遅くする2つの原因 where 句 - 検索のパフォーマンスを改善するためにインデックスを作成 等価 演算子 - 一致するキーの検索 プライマリキー - インデックスの使い方を確認 複合インデックス - 複数列に対するインデックス 遅いインデックス パートII - 前の問題点が再び 関数 - where句の 中での関数 大文字・小文字を区別する 検索 - UPPERと LOWER ユーザ定義 関数 - 関数インデックスの制限 インデックスの作り過ぎ - 冗長性の排除法 パラメータ化 クエリ - セキュリティとパフォーマンスのために 範囲 検
SQLデータベースに正しインデックスを作るのは 誰の役割？
SQLのパフォーマンス問題は、SQLそのものと同じぐらいの歴史がある―― ある人は、SQLはそもそも遅いものだとすら言うかもしれません。これは、SQLの歴史が始まった頃は正しかったかもしれませんが、今となっては全く 当てはまらないでしょう。にもかかわらず、SQLのパフォーマンス問題は今も一般的でよくあることです。どうしてそうなってしまうのでしょうか？ SQL言語は、恐らく最も成功した第4世代言語(4GL)でしょう。その最大の利点は、「何を」と「どのように」 を分離できることです。SQL文は、どのようにそれを実行するかを記述せずに、単純に 何を必要としているかのみの記述になっています。以下のような例を考えてみましょう。 SELECT date_of_birth FROM employees WHERE last_name = 'WINAND'SQLのクエリは、データを要求する英語の文として読
MySQL のJOIN に関するメモ - LukeSilvia’s diary
内容 FROM 句のテーブルの順番と、MySQL がテーブルをJOIN する順番は別 STRAIGHT_JOIN と eq_ref, ref eq_ref になるようにするために JOIN 条件の書き方 STRAIGHT_JOIN をいつ使うか 今回の検証に用いたMySQL は4.0.26。また、例として、以下のテーブルを用いる。(テーブルは、「逆算式SQL教科書」のもの) [study]> SHOW FIELDS FROM uriage; +-------------+---------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +-------------+---------+------+-----+---------+---------------
【SQL入門】group by,distinctどちらが性能がよいのか - 新卒から文系エンジニア→人材業界に転職した人のブログ
【今回の内容】 前回は基本的なＳＱＬを備忘録で簡単にまとめていたけど、 【SQL入門】基本的なSQLを目的別にまとめてみた - ＦＯＲ ＳＥ その中に気になることがあったので調べたものをメモとして紹介します。 今の自分の現場では、重複行を絞り込む時に、「distinct」と「group by」を使う人それぞれいました。 distinctとgroup byは同じように重複行を消すという意味では どちらでもいいのかなーと思っていたけど、 疑問に思ったので少し調べてみました。 【疑問】distinctとgroup by は重複行を消す目的ならどちらを使ってもよいのか？ 【結論】 結果としてはどちらも重複行を消すという意味では同じらしい。 だが、一般的にgroup byは集合関数（sumとかcountとか）と一緒に使うので、 そもそもの目的用途が違うのではという話があった。 また、どちらが性能が良
YappoLogs: なぜ SQL_CALC_FOUND_ROWS や LIMIT OFFSET のページングが良く無いのか
なぜ SQL_CALC_FOUND_ROWS や LIMIT OFFSET のページングが良く無いのか ここ最近の大規模サービス関連したデータページング考です。 mysql 5.5.34 で試して記事書いてます。 bigdata テーブルは id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, PRIMARY KEY (id) なカラムがある前提です。もちろん InnoDB です。 2014年なんだからCOUNT(*)とかSQL_CALC_FOUND_ROWSとかLIMIT OFFSETのページングはやめようぜ - Togetterまとめが発端にみえるけど、わりと昔から話されてる事なんだけど、「nippondanji SQL_CALC_FOUND_ROWS」でググっても有用な情報ないし文書化されてないからしとく。 ページング処理で使われがちな機能です。 S
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
PHPer が知るべき MySQL クエリチューニング/What PHPers Need to Know about MySQL Query Tuning
サービス終了のお知らせ
#jpoug ハイパフォーマンスを実現する設計方法とSQLチューニング実践講座@JPOUG> SET EVENTS 20151017のまとめレポ - もぐめぽろぐ
SlowQueryとの戦い
