こんにちは、みかみです。 今日のクラスメソッドのAWSおみくじ、RDS（t1.micro）でしたー！（昨日は Aurora！＠＠ｖ はじめに 前職＠アプリ開発時、MySQL のクエリチューニングをさせていただく機会がありました。 ユーザー入力のキーワードで全文検索 → 見つかったレコードを返すのですが、所要時間、約3分。。 Apache タイムアウトして画面真っ白。。。（泣きそうでした＞＜。 EXPLAINで実行計画を調べた際に、select_typeにはクエリの種類が表示されるのだが、代表的なサブクエリには次の3つのパターンがある。 SUBQUERY DEPENDENT SUBQUERY DERIVED 結論から言おう。遅いのは2番目、DEPENDENT SUBQUERYである。DEPENDENT SUBQUERYとはいわゆる相関サブクエリに相当するもので、サブクエリにおいて外部クエリの
"Nested Loop Joinしか取り上げて無いのにタイトルが大きすぎないか" と指摘を頂いたので、タイトルを修正しました。Merge JoinとHash Joinのことはまた今度書こうと思います。 「JOINは遅い」とよく言われます。特にRDBを使い始めて間がない内にそういう言説に触れた結果「JOIN=悪」という認識で固定化されてしまっている人も多いように感じています。 たしかに、JOINを含むようなSELECT文は、含まないものに比べて重たくなる傾向があることは事実です。また、本質的に問い合わせたい内容が複雑で、対処することが難しいものも存在します。しかし、RDBの中で一体どういうことが起きているのかを知り、それに基いて対処すれば高速化できることも少なくないと考えています。 本稿では、JOINの内部動作を解説した上で、Webサービスを作っているとよく出てくるJOIN SQLを例題に
1 (5) ( ) JPOUG> SET EVENTS 20120721 2012/07/21 2 • DB Oracle MySQL – RDBMS – Oracle MySQL 8 2 • Twitter @sh2nd • id:sh2 • 3 • – 1 http://d.hatena.ne.jp/sh2/20090802 – 2 http://d.hatena.ne.jp/sh2/20090816 – 3 http://d.hatena.ne.jp/sh2/20100112 – 4 http://d.hatena.ne.jp/sh2/20100510 • 4 • 2 4 5 • • A • D A • Apache Bench • Apache JMeter • HP LoadRunner B • SPECjbb2005 C • Oracle Real Application Te
Webシステム開発において性能試験を行う場合、hp LoadRunnerやApache JMeterといったウェブブラウザをエミュレーションしてくれる負荷テストツールを用いるのが定番だと思います。そんななか、たまにデータベース単体での性能を測ってほしいと頼まれることがあるので、そうした便利なツールはあるのかなと思って調べてみました。 データベースに対する負荷テストツールは探すとたくさん出てくるのですが、案件で使用しているRDBMSに対応していなかったり、トランザクション仕様が希望と異なっていたり、微妙に作りが悪かったりと、ニーズに合致したツールはすぐには見つかりません。そんなときにこのエントリがツール探しの参考になればと思います。 pgbench 対応RDBMS：PostgreSQL 対応OS：Linuxなど 言語：C 作者：石井達夫氏 ライセンス：独自(BSDライセンスに近い) トランザ
先日大きめ(といっても500万行くらい)のテーブルにインデックス付きのカラムを追加しようとして痛い目にあったので調査。 大きめのテーブルにカラムやインデックスを追加するとどうなるか 今回は単純に、「ALTER TABLE 〜 」で追加しようとしました。追加するカラムは3つで、 varchar(255) インデックスなし varchar(255) ↓のdate 型カラムとマルチカラムインデックスの形式のユニークインデックスあり date インデックスあり SQL を実行し、状況を「SHOW PROCESSLIST」で監視していたら、1つ目のカラム追加で次のような状態に… 最初にState が「copy to tmp table」状態になり、次の状態に遷移するまで1時間かかる 次にState が「Repair with keycache」状態になり、完了までに1時間かかる 次のカラム追加に対す
KLab Advent Calendar 2011 「DSAS for Social を支える技術」の2日目は、昨日に引き続き、MySQLを骨までしゃぶるためのテクニックです。 ソーシャルゲームは一般サイトよりもDBへの更新クエリの割合が多くなりがちです。更新クエリが多いMySQLでは、通常は有益なクエリキャッシュが無益どころか有害になります。 そもそもキャッシュヒット率が低い。20%以下なんてこともザラにある しかもクエリキャッシュの更新はグローバルなロックを取得する からです。特に後者は問題です。ただの参照クエリもクエリキャッシュを更新する上に、更新クエリはクエリキャッシュの全エントリをチェックして、更新したテーブルに影響がありそうな全キャッシュをdiscardしていくためです。たとえばユーザーの行動力のようなパラメータを格納した参照も更新も多いテーブルでクエリキャッシュが有効になって
前回書いたMySQLパフォーマンスチューニングのためのインデックスの基礎知識に引き続き、MySQLのパフォーマンスチューニングについて学んだことをまとめ。 MySQLを使っていると、クエリが遅い理由をつきとめる必要が出てくる。 どうやって遅いクエリをつきとめ、改善すればよいかについて学んだのでまとめた。 下記のような基礎知識があればパフォーマンスチューニングをうまくやれる、と思う。 クエリ処理の基礎 MySQLがクエリを処理する手順 まずはMySQLがクエリを処理する手順を知っておく必要がある。 処理は以下のような流れで進む。 クエリキャッシュの中からクエリの結果を探す。見つかればそれを返す。 クエリを解析して構成要素に分解する。 クエリの構文が正しいことを確認 クエリについて基本情報を収集する。 クエリを基本的な要素に分解した後、何を実行すべきかを判断する。 クエリオプティマイザが動き始
https://mariadb.com/kb/en/optimizer-switch/にあるように、MariaDBのオプティマイザはかなり改良されている。 では、MariaDBのオプティマイザ/エクゼキュータはどの程度優秀か、４つのSELECT文の実行を通してMySQLと(ついでにPostgreSQLと)比較してみる。 (2014.12.3追記：オプティマイザについては省略してますが、こんな本がでます。) 結論を先にいえば「MySQLは検索が速い」というのは都市伝説。MariaDBはがんばってるけどPostgreSQLにはまだまだ及ばず。 ＊念のため。これはベンチマークじゃないよ、オプティマイザ/エクゼキュータの機能比較です。 自分で再確認したい場合はこちらにスクリプト群と実験のやり方を簡単に書いたので参照のこと。 調査環境 同一マシンにMySQL5.6.14、MariaDB10.0.4、
MySQLのチューニングにおいて非常に重要となるメモリ(バッファ)関連のパラメータについて、 チューニングのポイント DSASのとあるDBサーバ(実メモリ4GB)の実際の設定値 をまとめてみます。 また、必要メモリの総量の計算や限界値を越えてないかチェックしてくれるスクリプトも紹介します。 是非、参考にしてみてください！ まず最初に注意点を。 バッファには2つのタイプがあります。 グローバルバッファ スレッドバッファ グローバルバッファはmysqld全体でそのバッファが1つだけ確保されるもので、 これに対し、 スレッドバッファはスレッド(コネクション)ごとに確保されるものです。 チューニングの際にはグローバル/スレッドの違いを意識するようにしましょう。 なぜなら、スレッドバッファに多くのメモリを割り当てると、コネクションが増えたとたんにアッという間にメモリ不足になってしまうからです。 in
Ringとは、リクルートグループ会社従業員を対象にした新規事業提案制度です。 『ゼクシィ』『R25』『スタディサプリ』など数多くの事業を生み出してきた新規事業制度は、 1982年に「RING」としてスタートし、1990年「New RING」と改定、そして2018年「Ring」にリニューアルしました。 リクルートグループの従業員は誰でも自由に参加することができ、 テーマはリクルートの既存領域に限らず、ありとあらゆる領域が対象です。 リクルートにとって、Ringとは「新しい価値の創造」というグループ経営理念を体現する場であり、 従業員が自分の意思で新規事業を提案・実現できる機会です。 Ringフロー その後の事業開発手法 Ringを通過した案件は、事業化を検討する権利を得て、事業開発を行います。 さまざまな事業開発の手法がありますが、例えば既存領域での事業開発の場合は、 担当事業会社内で予算や
大人のためのInnoDBテーブルとの正しい付き合い方。
InnoDB関連でよくある質問のひとつに「テーブルのメンテナンスは何をすればいいんですか？」というものがある。InnoDBはMySQL 5.5でデフォルトストレージエンジンとなるため、InnoDBのテーブルメンテナンス計画を立ようと思う機会も増えることだろう。そこで、今日はInnoDBのテーブルメンテナンスの各種方法となぜそうしなければいけないかという理由を解説しようと思う。 ANALYZE TABLEテーブルメンテナンスの代名詞といえば、インデックス統計情報の更新ではなかろうか。運用を続けるうちに、知らず知らずインデックス統計情報が狂ってしまい、思うような性能が出ない。RDBMSにはそのような問題がつきものであるが、InnoDBの場合、ANALYZE TABLEは不要である。なぜなら、InnoDBが自発的に統計情報を更新するからだ。InnoDBは以下の条件に適合すると、ANALYZE T
How Uber scaled its Real Time Infrastructure to Trillion events per day
平素よりQA＠ITをご利用いただき、誠にありがとうございます。 QA＠ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA＠ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、＠ITの今後のメディア運営方針などを検討した結果、2020年2月28日（金）15:00をもちましてQA＠ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA＠ITの7年間で皆さまの知識
こんにちは、keiです。 今回は、MySQLのチューニングに大活躍な「Jet Profiler」というツールをご紹介します。 Jet Profilerとは Jet Profilerは、MySQL向けのクエリアナライザです。 クエリチューニングは、DBパフォーマンスチューニングの中でも重要な作業の1つですが、 Jet Profilerを使えば、その作業をGUIで直感的に行うことができます。 フリーウェアの形態で提供されており、機能限定版であれば無料で利用することができます。 購入する場合は、$499となります。 詳細情報、ダウンロードは公式ページからどうぞ。 http://www.jetprofiler.com/ja/ Jet Profilerの魅力 その1 導入のしやすさ 通常のWindowマシンに、普通のアプリケーションをインストールする感覚でインストールが可能です。 イン
あくまで憶測で仮説でしかないんですが。 MySQL のストレージエンジンのうち代表的な二つ、MyISAM と InnoDB はよく MyISAM: Read は速いけどテーブルロックのため並行性が低い。運用が簡単。 InnoDB: MyISAM より Read は遅いけど並行性が高い 。行レベルロックなので。あとトランザクションや外部キー制約。運用が MyISAM よりちょっとめんどくさい。 という区別がされます。ここから転じて、 MyISAM は参照系クエリが大部分を占める場合に適用すると良い。例えば blog アプリケーションとか。 InnoDB は更新系クエリが多い場合に適用すると良い。 と言わたりします。実践ハイパフォーマンスMySQL でも第2章 ストレージエンジン(テーブル型) P.30 に アプリケーションでトランザクションを使用する必要がなく、主に SELECT または I
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
![[D14] MySQL 5.6時代のパフォーマンスチューニング *db tech showcase 2013 Tokyo](https://cdn-ak-scissors.b.st-hatena.com/image/square/7a1595d56a22d7e152f0c4c44cf3168a5c66fcbf/height=288;version=1;width=512/https%3A%2F%2F2.zoppoz.workers.dev%3A443%2Fhttps%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2F20131110tuningonmysql5-131117180858-phpapp02-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)
