理屈で考える、データベースのチューニング | Raccoon Tech Blog [株式会社ラクーンホールディングス 技術戦略部ブログ]
株式会社ラクーンホールディングスのエンジニア/デザイナーから技術情報をはじめ、世の中のためになることや社内のことなどを発信してます。 パフォーマンス勉強会OracleデータベースMySQLInnoDB こんにちは、羽山です。今回はOracleデータベースのチューニングで少し踏み込んだ内容です。途中で比較対象としてMySQLも登場します。 日頃からSQLチューニングの機会があってそれなりに得意としているのに、それでもなぜかパフォーマンスがでないSQLに悩んだ経験はありませんか？ 謎の遅い現象は特に大規模データベースになってくると発生しがちなのですが、速い場合も遅い場合も必ず理由があります。そこで本記事ではデータベースのチューニングにおいて意外と見落とされがちなローレベルな部分に着目して、さらに一歩上のパフォーマンスチューニングに必要な知識を解説します。 この記事を書くきっかけとなったのは私た
![理屈で考える、データベースのチューニング | Raccoon Tech Blog [株式会社ラクーンホールディングス 技術戦略部ブログ]](https://cdn-ak-scissors.b.st-hatena.com/image/square/2163d340456cff9037bacb3b1e5b6e672b06095e/height=288;version=1;width=512/https%3A%2F%2Ftechblog.raccoon.ne.jp%2Fwp-content%2Fuploads%2F2020%2F10%2Fdb_performance_slides-thumb.jpg)
知って得するInnoDBセカンダリインデックス活用術！
InnoDBはクラスタインデックスという構造になっている。今日はクラスタインデックスがどういうことかということを、皆さんに理解して頂きたい。もっとも理解して頂きたいポイントは「セカンダリインデックスのリーフノードには主キーの値が含まれている」ということだ。 主キーの構造InnoDBの主キーは次の図のように「データが主キーのリーフノードに含まれる」という構造になっている。このような構造をクラスタインデックスという。 このような構造になっていることには利点と欠点があるが、大きな利点は主キーの値で検索をすると非常に高速だということだ。主キーのリーフノードにたどり着いたときには、既にデータのフェッチも完了している。データとインデックスが別々に格納されているタイプのストレージエンジンでは、インデックスからデータの位置を読み取って、その後データファイルからデータをフェッチする。このように二段階の操作が
Apache JMeter で負荷試験をしよう!
© 2006 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice 2007 Apache JMeter 2007 1 30 2 19 2 14 • • Apache JMeter − • − − 3 19 2 14 • − • 2 − • − 4 19 2 14 • • • • • • Free Apache JMeter Apache JMeter 6 19 2 14 JMeter JMeter Jakarta / z z 100% pure Java Windows Linux z GUI z / z HTTP(HTTPS) FTP WEB z z Web 7 19 2 14 JMeter y y Java y y J
KOSHIGOE学習帳 - [MySQL] パフォーマンス関連メモ
MySQL :: MySQL 5.1 リファレンスマニュアル :: 13.5.11 InnoDB パフォーマンス チューニング ヒント MySQL :: MySQL 5.1 Reference Manual :: 13.6.13.1 InnoDB Performance Tuning Tips 長過ぎる PRIMARY KEY を避けてディスク領域の無駄遣いを避ける セカンダリインデックス用に余計な領域を使わないよう、長い主キーを避ける 主キーが長い場合、代わりに AUTO_INCREMENT なカラムを主キーとして作成するとよい 補足 MySQL :: MySQL 5.1 リファレンスマニュアル :: 13.5.13 InnoDB テーブルとインデックス構造 MySQL :: MySQL 5.1 Reference Manual :: 13.6.10.1 Clustered and Se
パーティショニングの使用例 - http session情報
今日もパーティショニングの話の続きである。 パーティショニングが非常にフィットする（たぶん昨日の例よりも）もう一つのケースは、数日間だけ必要なデータを蓄えておくような場合だ。例えば、HTTPセッションやログ情報などが良い例ではないだろうか。そういう場合には、日付を使ってRANGEパーティショニングをするのである。RANGEパーティショニングでももちろんPruningによって性能の向上は出来るのだが、それよりも何よりも高速に不要なパーティションを破棄できるというのが大きい。パーティションの破棄は、内部的にはテーブルのDROPとほぼ同じ扱いなのである。DROPのスピードはストレージエンジンによるが、InnoDBやMyISAM、NDB（MySQL Cluster）ならばいくらデータを含んでいても関係なくDROPは一瞬である。テーブルから大量の行を削除すると、フラグメンテーションが発生したり、イン
SSDの真の性能を引き出す MySQL 5.1.38 InnoDB Plugin - SH2の日記
X25-M、SSDで検索してくる方が非常に多いので、本ブログ内のSSD関連記事をリストしておきます。 MySQLのベンチマークを用いたIntel X25-M SSDの評価 (2009/03/25) SSDの真の性能を引き出す MySQL 5.1.38 InnoDB Plugin (本記事) MySQL 5.1.38から本体に同梱されるようになった、InnoDB Pluginの性能検証結果です。前回ご紹介したようにInnoDB Pluginには以下の強化点がありますが、本日はこのうちバックグラウンドI/Oスレッドの増加に焦点を当ててみたいと思います。 高速なインデックス作成。従来InnoDBのCREATE INDEXはテーブルの再作成を伴っていました テーブルとインデックスの圧縮 (検証結果その1、その2) INFORMATION_SCHEMAによるロック競合の検出 (検証結果) CPUスケ
HPCユーザが知っておきたい TCP/IPの話
HPCユーザが知っておきたい TCP/IPの話 ∼クラスタ・グリッド環境の落とし穴∼ 産業技術総合研究所 情報技術研究部門 高野 了成 2009年5月29日 SACSIS2009チュートリアル HPCユーザとTCP/IP 2 限界までネットワーク性能を出したい！ • グリッド環境で性能が出ないと悩んでませんか？ • 例）長距離大容量データ転送（帯域 1 Gbps、 RTT 100ミリ秒）におけるチューニング • デフォルト設定だとスループットは240 Mbps ☹ • 各種チューニングにより940 Mbps ☺ (2) HPCユーザとTCP/IP 限界までネットワーク性能を出したい！ • Ethernetで安価にPCクラスタを組めたが、性能も それなりと割り切っていませんか？ • 例）TCP/IPが苦手とする間欠通信の改善 （2秒ごとに10MBのデータの連続送信の繰り返し）
The Art of Work：MySQL InnoDB Pluginのデータ圧縮機能 性能編 - SH2の日記
MySQL InnoDB Pluginのデータ圧縮機能の続きです。前回はInnoDB Pluginの独自機能であるデータ圧縮の仕組みを解説し、Wikipedia日本語版のデータが約半分にまで圧縮されることを確認しました。今回はデータ圧縮によって性能がどのように変化するかを、実際にベンチマーク試験を行って見ていきます。 試験の方針 データ圧縮による性能への影響は、以下の二点が考えられます。 メリット：データサイズが小さくなるため、ディスクI/Oが減る デメリット：圧縮・展開の処理が行われるため、CPU負荷が高くなる そこで、これらの特徴がよく分かるように試験パターンを工夫します。Wikipedia日本語版のデータはInnoDB上でおよそ5GBありますが、まず狭い範囲に絞って読み取り処理を行うことでディスクI/Oがあまり発生しないようにします。これでCPU負荷の傾向を確認することができます。次
mod_xsend_file で画像配信サーバーの負荷軽減 : 管理人@Yoski
合宿で青い人に mod_xsendfile を教えてもらって「あわせて読みたい」に入れてみたら結構いい感じなのでメモ。 ■mod_xsendfile とは PHPなどのスクリプトから静的なファイル（画像ファイルなど）を送信するときに使う便利な apache モジュール。 ■仕組み header("X-Sendfile: （画像ファイルパス）"); と出力すれば、X SendFile がローカルから画像ファイルを引っ張ってきて、Last-Modified などのヘッダ情報をつけて後の処理をしてくれる。 つまり、スクリプトを使っていながら簡単に静的なファイルを送信しているように見せることができる。 （※セキュリティ設定に関係なく、任意のパスを指定できるところがミソ） ■「あわせて読みたい」では これまで、Location: ヘッダをつかってリダイレクトして画像を表示させていた。 この方式の欠点
パーティショニングの使用例 - カーディナリティが低いカラムを使って検索する場合
MySQL 5.1で追加された機能にパーティショニングがある。これは適切に利用すれば非常に強力な機能であることは間違いないのだが、使いどころが難しい。なぜなら、 インデックスをつけるだけでカバー出来る場合が多い。 パーショニングを使わずに、単にテーブルを分けてしまえばいい。 テーブルが巨大にならないとあまり効果を実感できない。 使い方を間違えると性能が落ちてしまう。 などの問題があるからだろう。 そんなわけで、今日と明日でパーティショニングが役に立つシーンを2つ紹介しようと思う。今日は一つ目、インデックスをつけたいカラムのカーディナリティが低い場合だ。カーディナリティとは日本語に訳すと濃度とか訳されるが、要は値の種類（分散具合）のことである。例えば、YesかNoの2つの値しかとらないカラムは非常にカーディナリティが低く、インデックスをつけるととても効率が悪い。インデックスを使って目的の行を
MySQLのEXPLAINを徹底解説!!
以前、MySQLを高速化する10の方法という投稿で「EXPLAINの見方についてはいずれ解説しようと思う」と書いてしまったので、今日はその公約？を果たそうと思う。 MySQLのチューニングで最も大切なのは、クエリとスキーマの最適化である。スキーマの設計は一度決めてしまうとそのテーブルを利用する全てのクエリに影響してしまうためなかなか変更することは出来ないが、クエリはそのクエリだけを書き直せば良いので変更の敷居は低い。そして遅いクエリをなくすことは、性能を大幅に向上させるための最も有効な手段である。従って、アプリケーションの性能を向上させたいなら、まず最初にクエリのチューニングを検討するべきなのである。 最適化するべきクエリはスロークエリログやクエリアナライザで見付けられるが、ではそのようなクエリが見つかった場合にはどのように最適化すればいいのか？そのためにはまず現在どのようにクエリが実行さ
qmailとPostfixのパフォーマンス比較 - matabii's blog
今の環境がqmailで、今後どちらを使うか？と言われるとPostfixなのですが、心置きなく移行するために速度の比較を行ってみました。ベンチを取るならPostfixにsmtp-sourceというソフトがついているのですが、実際に送信した時のパフォーマンスが見たかったので、実験サーバ計4台とDNSを立ち上げて普通の環境に近い形で比較しました。 実験環境（送信サーバ） OS：CentOS5.2（素カーネル2.6.18） CPU：Xeon X3220 2.4GHz core*4 メモリー：4GB qmail-1.03 /var/qmail/control/concurrencyremote /var/qmail/control/concurrencylocal 上二つを120で作成し、配送プロセス数の上限を120にしました。 postfix-2.3.3-2 default_process_lim
なぜMySQLのサブクエリは遅いのか。
よくMySQLはサブクエリが弱いと言われるが、これは本当だろうか？半分は本当で半分は嘘である。MySQLのサブクエリだってなんでもかんでも遅いわけではない。落とし穴をしっかり避け、使いどころを間違えなければサブクエリも高速に実行できるのである。今日はMySQLがどんな風にサブクエリを実行し、どのような場合に遅いのかということについて説明しよう。 EXPLAINで実行計画を調べた際に、select_typeにはクエリの種類が表示されるのだが、代表的なサブクエリには次の3つのパターンがある。 SUBQUERY DEPENDENT SUBQUERY DERIVED 結論から言おう。遅いのは2番目、DEPENDENT SUBQUERYである。DEPENDENT SUBQUERYとはいわゆる相関サブクエリに相当するもので、サブクエリにおいて外部クエリのカラムを参照しているサブクエリのことである。そし
Using filesort
去年ソートに関する記事を書いたが、今日はその続きである。 MySQLでEXPLAIN SELECT...を実行するとExtraフィールドでよく見かける「Using filesort」という文字列。Filesortって一体なんだろう？と思ったことはないだろうか。単刀直入に言ってFilesortの正体はクイックソートである。 クエリにORDER BYが含まれる場合、MySQLはある程度の大きさまでは全てメモリ内でクイックソートを処理する。ある程度の大きさとはsort_buffer_sizeであり、これはセッションごとに変更可能である。ソートに必要なメモリがsort_buffer_sizeより大きくなると、テンポラリファイル（テンポラリテーブルではない）が作成され、メモリとファイルを併用してクイックソートが実行される。 Filesortは全てのソート処理において実行されるわけではない。前回の記事
オトコのソートテクニック2008
今日は仕事納めだったので、一年の締めくくりとしてMySQLにおけるソートの話でもしようと思う。 インデックスを利用しないクエリで最もよく見かけるもののひとつは、ORDER BYを用いたソート処理だろう。もし、ソート処理においてインデックスを用いることが出来れば、MySQLは結果を抽出してから結果行をソートするのではなく、インデックス順に行を取り出せば良いので高速にソート処理することが可能になる。特に、LIMIT句やWHERE句を用いて行の絞り込みを行う場合は効果が絶大である。しかし、ひとたびインデックスを利用できない状況に直面すると、たちまちテーブルスキャンが発生して性能が劣化してしまう。 例えば、100万行のレコードを格納したt1というテーブルがあるとする。そのテーブルに対して以下のようなクエリを実行した場合を考えよう。 mysql> SELECT col1, col2 ... colx
Chromeはなぜ速いのか － ＠IT
Chromeの動作が圧倒的に速いように感じている。Chromeがリリースされた当初、それがなぜなのかよく分からなかった。グーグルだけにできて、ほかのWebブラウザ開発者にできないことなどあるように思えないが、それにしてはあまりに速いように感じたからだ。 その疑問のほとんどは、Chromeのオープンソースプロジェクト版「Chromium」の公式ブログの解説で氷解した。ブログを読んで分かったのはグーグルのエンジニアたちが信じられないほどのスピード狂であることと、そのスピードへのこだわりには2種類の“スピード”があることだ。 1つは処理速度、もう1つは応答速度だ。特に後者、ユーザーをできるだけ待たせない、イラつかせないということに対する徹底したこだわりは、すさまじい。その背後には「スピードとは、つまりお金だ」という洞察があるようだ。 0.5秒の遅延でユーザー離れ グーグル創業約1年後の1999年
Using filesortにORDER BY NULL - Enjoy*Study
巨大なテーブルを結合し、テーブルをまたいだ複数キーでGROUP BYするSQLを書いてEXPLAINで実行計画を確認したところ、見たく無いものが出てしまいます。 Using temporary; Using filesort テーブル結合自体はINDEXを使えているようですが(EXPLAINの結果から)、GROUP BYは、テーブルまたいてしまっているので、INDEXが使えていないのかな、、なので「Using temporary」はしょうが無いと思ったけれども、「Using filesort」が出るのが良くわかりません。 GROUP BYって、内部的にソートされるのが当然なのか！？って思ったけれども、どうもデフォルトの動作でGROUP BYの場合にソートが行われてしまう模様。 MySQL 4.1 リファレンスマニュアル :: 5.2.1 EXPLAIN 構文（SELECT に関する情報の取
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.mysqlpracticewiki.com/index.php/MySQL%E3%82%B5%E3%83%BC%E3%83%90%E3%81%8C%E6%B6%88%E8%B2%BB%E3%81%99%E3%82%8B%E3%83%A1%E3%83%A2%E3%83%AA
http://www.mysql.gr.jp/Manual/mysql-3.21.31/manual_Performance.html
【Sun Tech Days 2008セッションレポート】「MySQL: Database for Web 2.0」
