はじめに 今までは適切なデータを抽出するクエリの書き方しか視野に入れられませんでしたが、次第にパフォーマンスのことも考慮するようになりました。 複雑なSQL文になればなるほどかなり重要になってくるので、少しでもパフォーマンスが改善できる記載を備忘録として残そうと思います
【SQL】すぐに使えるパフォーマンス改善 - Qiita
はじめに 今までは適切なデータを抽出するクエリの書き方しか視野に入れられませんでしたが、次第にパフォーマンスのことも考慮するようになりました。 複雑なSQL文になればなるほどかなり重要になってくるので、少しでもパフォーマンスが改善できる記載を備忘録として残そうと思います
SQLの達人への道: MySQLでの高速・効率的クエリ作成術 - Qiita
データベースとテーブルの作成 テスト用のデータベースtestdbを作成し、パフォーマンスチューニングを検証するためのcompanyおよびpersonテーブルを定義します。 CREATE DATABASE testdb; USE testdb; CREATE TABLE company ( company_id INT AUTO_INCREMENT PRIMARY KEY, company_name VARCHAR(255) NOT NULL, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE person ( person_id INT AUTO_INCREMENT PRIMARY KEY, company_id INT, person_name VARCHAR(255) NOT NULL, email VARCH
外部結合とサブクエリのどっちが早いか試してみた - うなの日記
おとついの不具合の対応案として挙げた「外部結合を使う案」と「サブクエリを使う案」でどっちが早いか試してみた。 環境/条件等 DBはMySQLではなく実運用で使うDB2を使用。 テーブルは以下。おとついのサンプルからカラムを少し増やしてます。 create table A ( id BIGINT NOT NULL GENERATED AS IDENTITY, a VARCHAR(20) NOT NULL DEFAULT '', b VARCHAR(20) NOT NULL DEFAULT '', c VARCHAR(20) NOT NULL DEFAULT '', PRIMARY KEY(id) ) IN test_32k create table B ( id BIGINT NOT NULL GENERATED AS IDENTITY, a_id BIGINT NOT NULL, a VA
ケース別ゆるふわテーブル結合
これは ミライトデザイン Advent Calendar 2022 の 11 日の記事です。 前日は polidog@PartyHard Inc. さんの CSS in JS と Stitches について でした。 今年もミライトアドカレで polidog さんの記事が読めて嬉しいです、ありがとうございました！ 記事の翌日紹介でスーパープログラマなんて言われちゃった、やったね♪ なんて喜んでもいられず、今年は得意でもない DB について「ゆる〜い Join の記事」と「ちょっとマジメな Index の記事」を書くんですが、ゆる〜い気持ちで備えていた今日のハードルが不意打ち気味にブチ上がっています。 みなさん、Join は得意ですか？ 「どうも join がいつもすぐ書けんのう」 「left だの inner だのと、細かいことは知らんぞい」 「どのワードが略せるとか略すとどうなるとか、覚
高効率なSQLクエリの書き方 - Qiita
概要 この記事では、SQLクエリをより効率的に記述するためのベストプラクティスとテクニックに焦点を当てています。データベースのクエリはシステム全体のパフォーマンスに直結するため、最適な書き方を知ることは重要です。インデックスの効果的な活用方法、適切な結合の選択、そして条件の効果的な書き方など、SQLの最適化に関する具体的な手法を解説します。各SQL文に関する実行計画の結果も掲載していますので、ぜひご確認ください。 なお、Oracle19cとOracle12cでの利用実績がありますが、他のデータベースやバージョンにおいての検証は行っておりません。 新しい情報は随時追加されますので、お楽しみにしてください。 SQLの最適化に関連する基本的なアイデア 以下の通りと考えています。 1.インデックスの利用 2.正しいJOINの選択 INNER JOIN、LEFT JOIN、RIGHT JOINなど、
社内向け SQLチューニング勉強会を実施しました
はじめのご挨拶 はじめまして。BEENOSの鈴木です。 普段はBEENOSグループのtenso株式会社でヘルプデスク業務に従事しておりますが、たまにサービス関連のデータベース、MySQLのチューニングや調査などもしております。 今回、普段から触っているMySQLのチューニング勉強会を実施しましたので、その内容を少し公開したいと思います。 勉強会を開催しようとしたきっかけ tenso株式会社の開発チームには、SREチーム（運用チーム）があり、元々は私も所属しておりました。 SREチームに新規メンバーが参入してきたこともあり、改めてデータベースと向き合う人のために、まずはSQLのチューニングを覚えてもらいたいとの要望があり、開催することにしました。 また、BEENOS全体としても開発エンジニアがコードを書くだけでなく、コードに含まれているSQLがどのように動くかを把握しパフォーマンスの良いSQ
【SQL】ちょっとしたパフォーマンスチューニングまとめ - Qiita
SELECT table_a.id, table_a.name FROM table_a INNER JOIN table_b ON table_a.id = table_b.id; メリットとしては、 どちらかのテーブルのid列のインデックスを使用可能 サブクエリがないことで中間テーブルが作成されない しかし、インデックスがない場合はEXISTSの方が良い場合があります ソートの回避 SQLでは暗黙的にソートが発生する演算が存在するので、 パフォーマンスにも影響するため、ソートが必要ない場合は考慮する必要があります ソートが発生する演算 GROUP BY句 ORDER BY 句 集約関数（SUM, COUNT, AVG） DISTINCT 集合演算子（UNION, INTERSECT, EXCEPT） ウィンドウ関数（RANK, ROW_NUMBER 等） メモリ上でのソートだけではなく
MySQLとOracleの実行計画を比較してみた - ASMのきもち
まいえすきゅーえりたい ぽすぐれない おらくるってる（狂ってる）tomoです。 今日はいつものMySQLリファレンスを読むではなく、夏休みの宿題にしていたこれをやってみます。 MySQLとOracleDBの実行計画を比較してみた さて同じようなテーブルで同じデータを載せて。 実行計画を取ってみた時、どのくらい情報量が違うのか簡単に違いを見てみましょう。 前提として、以下をご認識ください。 一方はOSSのDBエンジン、もう一方はガチガチ商用DBエンジンです。情報量が違うのは当たり前であって、良し悪しを比較したいのではありません。そして製品比較をしたいのではありません。いつも商用DBメインで使っているエンジニアが、OSSのDBにこうゆう情報も出してほしいな！というのをお願いしたいと思っていて、それを考える元ネタメモだと思ってください。 OSSでこれだけの情報出せるMySQLや、今回紹介しません
SQLが重いからLimitで件数絞ろう！は正しいのか？というお話。 - Qiita
この記事はQiita Engineer Festa 2023 参加記事です。 この記事で書くこと パフォーマンスチューニング（クエリチューニング）を行う際の勘所としてSQLの見直し方を書きます。 この記事で書かないこと あくまで勘所として見る部分を書くので、RDBMSそれぞれ固有のことや深いことは書きません。 SQLが重いからLimitで件数絞ろう！は正しいのか？というお話。 SQLチューニングの勘所 システムのパフォーマンスチューニングを行う上で、ボトルネックになっているのは大体DBのIOの部分ということが多いです。 SQLチューニングの勘所を抑えておくことで、爆速Webサービスを作っていきましょう。 いきなり結論 問い： SQLが重いからLimitで件数絞ろう！は正しいのか？ 回答 正しくない！ とは言い切れないが、効果が薄いことが多い。 ↑もったいぶってすいません。折りたたみを使って
SQLの実行計画の読み方 |
今回は、SQLを書く上で特にパフォーマンスに影響のあるSQLの実行計画の読み方について解説します。実行計画はデータベース製品によってさまざまに差異がありますが、ここでは比較的どのデータベース製品でも共通する内容について解説します。 実行計画とは記述したSQLが実際にデータベースの内部でどのように処理されて結果を返すか、その処理方法を記述した情報です。 A5:SQL Mk-2では、SQLエディタで実行計画を見たい SQL の上にキャレットがある状態でメニューから [SQL(S)] – [SQLの実行計画(J)] または、Ctrl+E で表示できます。 表示の仕方はデータベース製品ごとに異なりますが、多くのデータベース製品ではツリー状の情報として表現されます。（このため A5:SQL Mk-2でもツリービューで実行計画を表示します。） ツリーのリーフ（端）から処理が行われ、ルート（根）に向かっ
ChatGPTにSQLチューニングさせてみた - Qiita
ChatpGPT（モデルはGPT-4を利用）にシンプルなSELECT文とテーブル・インデックス定義を与えてSQLチューニングの案出しをしてもらいました。 ちなみに、プロンプトやChain of Thought などの工夫は一切せず、シンプルに質問をぶつけています。 以下、注意事項。 実務利用と比べるとシンプルすぎるのでお遊びの範囲を超えていません。 どのチューニング案が適切かは多くの要素（例えば以下）が関わってくるので、一概に判断できず実際に測定を行い確認する必要があります。 データ量やその分布 ハードウェアやRDBMSの種類・バージョンなどの環境 性能要件（何秒以内のレスポンスが必要か、同時実行数はいくつかなど） ChatGPTへの質問とその回答 1. 単純なインデックスが不足しているケース 質問 以下のSQL文の性能を改善するにはどうしたらよいでしょうか。 select custome
あなたの遅延はどこから？ SQLから！ 〜患部に止まってすぐ効くSQLレビューチェックリスト 年初め特大サービス号〜 - ANDPAD Tech Blog
あけましておめでとうございます！ 今年は異世界放浪メシのアニメが放送されるらしいので楽しみなバックエンドの原田 (tomtwinkle)です。 内部で運用しているSQLレビューチェックリストの一部を抽出し思いつきで追記して行った結果、結構な分量になってしまいました。 暇な時でも流し読みして頂けるとありがたいです。 Motivation SQLレビュー観点 大きくSQLが変更される修正の際にはEXPLAINをレビュー内容に加える 検索のキーにINDEXを使用しているか SQL発行回数がN+1(1+N)の構造になっていないか サブクエリを利用したSQLはパフォーマンス要チェック Viewの利用は基本的に禁止 CROSS JOINは禁止 WHERE句で十分に絞った検索をしているか 必要なcolumnだけSELECTしているか レコード数だけ必要な場合にCOUNT用のSQLを発行しているか 集計関
SQLを速くするぞ―お手軽パフォーマンス・チューニング
このサイトでは、SQL を高速化するためのちょっとしたパフォーマンス・チューニングの技術を紹介します。と言っても、『プログラマのためのSQL 第2版』の受け売りがほとんどなので、この本を読んでいただければ、本稿を読む必要はありません。 最初に、パフォーマンス・チューニングに関する全体の方針を述べておくと、それはボトルネック（一番遅いところ）を改善することです。当たり前ですが、既に十分速い処理をもっと速くしたところで、システム全体のパフォーマンスには影響しません。従って「処理が遅い」と感じたら、最初にすることは、SQL やアプリの改修ではなく、「どこが遅いのか」を調査することです。いきなりあてずっぽうで改善をはじめても効果は出ません。医者が患者を診るとき最初にすることが検査であるのと同じです。病因が何であるかを突き止めてからでないと、正しい処方はできないのです。 その基本を承知していただいた
【SQL】今日からできるクエリチューニング - Qiita
はじめに 達人に学ぶSQL徹底指南書を読んでいてクエリチューニングの章があったので、 この機会に本書および各種記事から学んだクエリのチューニング方法の中で すぐに実践可能なものをまとめてみようと思います。 記載する内容は DBMS の種類やテーブルに格納されている データによっても結果が変わってきますので、 必ずしもパフォーマンスが改善される訳ではないという点にご留意ください。 クエリチューニング方法 SELECT ではカラム名を指定する SELECT * を使用すると不要なカラムまで取得してメモリを圧迫したり、 実際のカラム名への変換が発生するため、必要なカラム名のみを指定する。 テーブルにエイリアスを付ける テーブルに別名を付けておくと、クエリ解析時にカラムがどのテーブルのものかを 判別する処理を省略可能。特に複数のテーブルを参照する場合に有効。
SQL改善で処理時間を約98%カットできた話 - Qiita
概要 私は株式会社ZUUで、主にバックエンドの開発を担当しており、フロントエンド、インフラに関する業務も担当しています。 今回取り上げる内容は、SQLの書き方一つでパフォーマンスがどれだけ改善できるかを、実例をもとに記述していきます。 シナリオ 使用しているDBMSはPostgreSQL12です。 話を単純化するために単純な例で説明します。今回は投稿記事を管理するケースを想定します。投稿される記事には複数の画像が載っており、全ての画像がアップロード完了していれば記事として有効なものと考えます。 テーブルはarticles, imagesを用意します。 実際にデータを入れてみるとこんな感じ。 articles id title published_at
ISUCON12 予選の解説 (Node.jsでSQLiteのまま10万点行く方法) : ISUCON公式Blog
ISUCONとはLINEヤフー株式会社が運営窓口となって開催している、お題となるWebサービスを決められたレギュレーションの中で限界まで高速化を図るチューニングバトルです ISUCON12 予選の解説 (Node.jsでSQLiteのまま10万点行く方法) こんにちは、面白法人カヤックのacidlemonです。例年ISUCONに参加するたびにとても長い「やったこと」ブログを書いているので、もしかしたらそちらを読んだことがある人もいるかもしれません。 ISUCONの公式サイトに記事を書くのは ISUCON3の予選の解説 以来でしょうか。今回もacidlemonが解説、fujiwaraが講評を書く予定ですので、お楽しみに。あ、そういえば先日掲載していただいた 面白法人カヤックからの応援メッセージ の脳内インタビューも私が書いていますのでよく考えたらそれ以来ということになるのかもしれません。予選
SQLが突然遅くなる原因と対応方法 | SE日記
ここではORACLEデータベースのSQLが急に遅くなる原因と対処方法について紹介してきます。 SQLの実行計画の見方や確認方法については↓で紹介していますので参考にしてください。 ＞＞【ORACLE】SQLの実行計画の見方 ＞＞【ORACLE】SQLの実行計画を取得する方法 SQLが突然遅くなる原因と対処方法 SQLが突然遅くなる原因を3つ紹介しています。 １．統計情報が古い ２．実行計画が最適でない ３．リソース不足 以上の3つです。 以降でもう少し詳しく紹介していきます。 １．統計情報が古い ORACLEがSQLを実行するとき、表の統計情報を元にどのようにしてデータを取得するか、実行計画という計画を作成します。 表の中のデータが増えたり減ったり、月末処理などで大量の更新がかかりデータの内容が大きく変わってしまったりすると表の統計情報が古くなっていることがあります。 そのとき、最適な実行
1文字でSQLを200倍遅くする方法
こんにちは、19のSysAd班の翠(sappi_red)です。普段はtraQのフロントエンドの保守を行ったりしています。 こんばんは、19のSysAd班のtemmaです。普段は普段どおりのことをしています。この記事の面白い部分はすべて僕が書いています。面白くないところは翠君が書いています。 この記事では、日々パフォーマンスに頭を悩ませる開発者の方のために、ワンタッチで劇遅SQLを200倍高速でキュートなSQLに劇的ビフォーアフターする方法を紹介します。 「おいおいおい、遅くしたくて記事を読み始めたのに話が違うじゃないか💢」と思ってるそこのあなた👈 早くできるということは遅くもできるんですね。 TL;DR ここにテーブルがあります。 CREATE TABLE messages ( id CHAR(36) NOT NULL PRIMARY KEY, text TEXT COLLATE ut
MySQLでIN句の中に大量の値の入ったクエリがフルスキャンを起こす話 - freee Developers Hub
こんにちは、freee Developers Advent Calendar 2021、19日目のid:shallow1729です。昨日はtdtdsさんで【マジで】サイバー演習シナリオの作り方【怖い】でした！障害訓練後に攻撃方法を解説された時はリアリティの高さに驚きました。 僕はMySQLを使っていて発生した不思議な挙動の調査の話をしようと思います。 今回問題となったクエリ 今回話題にするクエリは以下のようなシンプルなものです。 SELECT * FROM hoge WHERE id IN (...) MySQLのパラメーター次第ですが、デフォルトの設定だとこのIN句の中の値の数が数万になると適切なインデックスが用意されていてもフルスキャンが発生する事がありました。このクエリがテーブルのほとんどのレコードを網羅するような場合や高速でレコードを大量にinsertして統計情報が追いつかないケー
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
キャッシュと向き合う、キャッシュと共に生きる / cache pattern
