クエリのパフォーマンスチューニングの第一歩。実行計画や統計情報について入門する
SQL実行の流れ まずはSQLがどのような流れで実行されるのかを見ていきます。 SQL実行の流れは大まかに捉えると以下のようになります。 パーサ パーサでは、ユーザーから送信されたクエリを受け取り、その文法的な正確さを検証します。SQLクエリが正しくフォーマットされているか、必要な構文要素が全て含まれているかをチェックし、例えばFROM句で指定されたテーブルが存在するかどうかも確認します。 文法的なエラーがある場合、例えばカンマの欠落や存在しないテーブルの参照など、クエリはエラーとして返されます。 エラーがない場合は、クエリは「抽象構文木」というデータ構造に変換されます。これにより、データベースはクエリをより効率的に解析し、次の処理ステップに進めることができます。 オプティマイザ SQLクエリがパーサを通過した後、次にクエリの最適化を行うのが「オプティマイザ」です。オプティマイザの主な役割
スロークエリを改善したらECSの負荷が爆下がりした話(TypeORM)
TL;DR TypeORMで発生していたスロークエリを改善 スロークエリを改善したらECSの負荷も減少 はじめに スロークエリを改善したら、ECSコンテナ側の負荷も下がってなんでだろ？と思ったので記事にしようと思います。 環境 TypeORM v0.3.20 Node.js v18.x バックエンドインフラ ECS on Fargate => Amazon Aurora MySQL 負荷改善の前と後 まずはどのくらい改善したのかを示します。 この時ECSコンテナ8台動いてました。(4vCPU 8GBMem) 改善前 改善後 改善前と改善後は一日前の同じ時間帯のものです。 ちゃんと動いてるのか不安になるくらい下がってました笑 どのような対応をしたのか スロークエリの出ていたクエリでMySQLの実行計画を確認しました。 TypeALL,index, Using Filesort等はなかったので
MySQL(InnoDB)のSQLパフォーマンスチューニングのエッセンス
はじめに MySQL(InnoDB)でSQLのパフォーマンスチューニングをするときに役に立つ知識をエッセンスとしてまとめました。結合(JOIN)やB-treeインデックスの探索の仕組み、実行計画の基本的な見方を紹介します。 想定する読者は、SQLのパフォーマンスを改善する必要があるが実行計画をみてもいまいちピンと来ない方です。インデックスの作成の経験や、複合インデックスやカーディナリティの知識があることを前提にしています。目標は、実行計画の内容がよく分からない読者が、実行計画をみただけでクエリが実行される様子をイメージでき、自信を持ってクエリの改善にあたることができるようにすることです。 ストレージエンジンはInnoDBを前提としています。また、インデックスはB-treeインデックスを想定しています。全文検索の転置インデックスや空間検索のR-treeインデックスについては触れません。 イン
2008-06-29
mysqlを利用していて、indexをちゃんと張っているのにパフォーマンスが出ない。 explain でも type = ref / key = INDEX 等が表示されているのにすごくクエリーが遅かったりする。 思い切って index を消したら逆にパフォーマンスが改善した! why? データ件数が数万件を越えたあたりからパフォーマンスが劇的に下がった。 と、悩んでいたりしませんか? そんな悩みのひとつの解決策になってくれるかもしれません。 テストは vmplayer 上の debian etch で行います。 ホスト環境 intel Q6600 メモリ2Gの WindowsXPです。 クエリーをキャッシュされないように、クエリキャッシュを 0 にします。 /etc/mysql/my.cnf query_cache_size = 0 #no cahce debug swapで遅くなると困
『MySQL初心者に贈るインデックスチューニングのポイントまとめ2014』
サイバーエージェント公式ブログをご覧の皆さんこんばんは、インフラ＆コアテク本部の須藤(@strsk)です。普段はAmebaのソーシャルゲーム全般のインフラを見つつ、日本語ラップの啓蒙をしながら弊社社員を素材にコラ画像をつくったりしています。好きなAAは麻呂です。 はい、というわけで今回はMySQLインデックスチューニングの基本的な流れについてまとめてみました。 ソーシャルゲームは更新も参照もめちゃくちゃ多いです。数秒のレプリケーション遅延も致命的なので適切なテーブル、クエリとインデックス設計が重要です。（何でもそうですけど）インデックスが多くなると更新コストなどが懸念されますが、インデックスが正しく使われていないクエリを放置している方が悪です。そんなこんなで、割と例も偏ったりしてるかもしれませんがあしからず。 前提としてはInnoDBを想定しています。MyISAMはほとんど使っていません。
なぜ、SQLは重たくなるのか？──『SQLパフォーマンス詳解』の翻訳者が教える原因と対策｜ハイクラス転職・求人情報サイト AMBI（アンビ）
なぜ、SQLは重たくなるのか？──『SQLパフォーマンス詳解』の翻訳者が教える原因と対策 『SQLパフォーマンス詳解』の翻訳者の松浦隼人さんに、8つの「SQLが重たくなる原因とその対策」を聞きました。システムのボトルネックになるような「問題のあるSQL」を回避するノウハウを学びましょう。 データの操作や定義をする言語「SQL」は、どのような領域を担うエンジニアにとっても必修科目です。しかし、その仕様をきちんと理解し、パフォーマンスに優れたSQLを書ける方はそれほど多くありません。問題のあるSQLを書いてしまい、知らぬ間にそれがシステムのボトルネックになってしまう事態はよく発生します。 では、どうすればそうした事態を回避できるのでしょうか？ そのノウハウを学ぶため、今回は『SQLパフォーマンス詳解』の翻訳者であり、自身もエンジニアでもある松浦隼人（まつうら・はやと／@dblmkt）さんに8つ
SQL Server のチューニングについてまとめてみる - その1 - ( インデックスの調査 ) - 都内で働くSEの技術的なひとりごと / Technical soliloquy of System Engineer working in Tokyo
SQL Server のチューニングについてまとめていこうかと思います。まずは、インデックスを使用していないクエリの抽出方法です。SQL Server のチューニングには、dm_* で始まる動的管理ビューを多用します。今回は、主に以下の3テーブルを使用して、インデックスを使用していないクエリを探してみましょう。 sys.dm_db_missing_index_group_stats 欠落インデックス グループに関する情報を取得します。 sys.dm_db_missing_index_groups sys.dm_db_missing_index_group_stats と sys.dm_db_missing_index_details を JOIN するために必要なテーブルです。 sys.dm_db_missing_index_details 欠落したインデックスについての詳細情報を取得しま
PHP製のWebアプリが遅い場合の基本チェック6点 - ほんじゃらねっと
先日別のチームから、 「PHPで作成したWebアプリの速度が遅いので助けてくれー」 という相談を受けた。 対応したものの、結構時間がかかって面倒だったので、 今後こういった問題が起こった時に使えるよう、チェックリストをまとめてやった。 基本的な内容だけど、 このチェックリストの内容をやってみて、それでもダメなら相談しなさい、 と伝えておくことで相談を減らすフィルタとして働いてくれるはずだ。 PHPプロジェクトに限らず、バックエンドでデータベースを使用している Webアプリのプロジェクトなら試す価値のあるものが多いはず。 調査や対応方法の手軽さ順で並べるとこんな感じ: Webブラウザのデベロッパーツールでレスポンスを計測する Webサーバ(Apache)のリクエスト時間をログに出力する ログ解析ツールでURL毎の付随リクエスト数を確認する データベースのスロークエリログを出力する プロファイ
ユーザーの体感速度を高めるためのJavaScriptチューニング（前編）
連載「Webサイト・アプリ高速化テクニック徹底解説」第2回は、JavaScriptの高速化について、まずは前編、後編に渡ってユーザーの体感速度を向上させるための方法を紹介します。JavaScriptの同期・非同期の仕組みやscript要素のasync属性、defer属性について詳しく解説します。 今回から複数回に分けて、JavaScriptの高速化をテーマに解説していきます。まずは、ユーザーの体感速度を高めるためのJavaScriptチューニングということで、単純なJavaScriptの構文によるスピードを比較するようなものではなく、主にユーザー視点からの高速化を主眼に解説します。その中で、同期・非同期といったJavaScriptの仕組みやscript要素のasync属性、defer属性などについても触れていきます。 ユーザーの体感速度を向上させる 一概にJavaScriptの高速化といっ
データベース負荷テストツールまとめ(1) - SH2の日記
Webシステム開発において性能試験を行う場合、hp LoadRunnerやApache JMeterといったウェブブラウザをエミュレーションしてくれる負荷テストツールを用いるのが定番だと思います。そんななか、たまにデータベース単体での性能を測ってほしいと頼まれることがあるので、そうした便利なツールはあるのかなと思って調べてみました。 データベースに対する負荷テストツールは探すとたくさん出てくるのですが、案件で使用しているRDBMSに対応していなかったり、トランザクション仕様が希望と異なっていたり、微妙に作りが悪かったりと、ニーズに合致したツールはすぐには見つかりません。そんなときにこのエントリがツール探しの参考になればと思います。 pgbench 対応RDBMS：PostgreSQL 対応OS：Linuxなど 言語：C 作者：石井達夫氏 ライセンス：独自(BSDライセンスに近い) トランザ
Kazuho@Cybozu Labs: MySQL のボトルネックを統計的に監視・解析する方法
MySQL のチューニング、と言った場合には、サーバーパラメータの調整や EXPLAIN コマンドを利用したクエリ実行計画の最適化が話題に上ることが多いです。しかし、発行する全ての SQL について、いちいち EXPLAIN コマンドを使って確認していては、いくら時間があってもたりません。チューニングを効率的に進めるには、まず、ボトルネックとなっている SQL クエリを特定し、次にその最適化を行うべきです。 ではどのようにして、ボトルネックを特定するのか。MySQL Conference & Expo 2009 のキーノートにおいて Mark Callaghan 氏は、Google では SHOW PROCESSLIST コマンドを使った統計的アプローチを使っていると述べていらっしゃいます (参照: MySQLConf 09: Mark Callaghan, "This is Not a
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
