key_buffer_sizeとは、「インデックスブロック用に使用されるバッファメモリの最大値」をあらわします。MySQLのリファレンスマニュアルでは、しばしば「インデックス＝キー」として表現されています。つまり「作成したインデックスをメモリ上に維持しておくために、物理メモリ上に確保するバッファの最大値」ということになります。 key_buffer_sizeはデフォルト状態では以下の通り約8Mbytesに設定されています。
[ThinkIT] 第5回：key_buffer_sizeの違いによるパフォーマンス比較 (1/3)
key_buffer_sizeとは、「インデックスブロック用に使用されるバッファメモリの最大値」をあらわします。MySQLのリファレンスマニュアルでは、しばしば「インデックス＝キー」として表現されています。つまり「作成したインデックスをメモリ上に維持しておくために、物理メモリ上に確保するバッファの最大値」ということになります。 key_buffer_sizeはデフォルト状態では以下の通り約8Mbytesに設定されています。
[ThinkIT] 第1回：定量的な情報収集のススメ (1/3)
MySQLサーバに限らず、大量のアクセスを処理するデータベースやアプリケーションサーバ群に対して、それぞれの環境に合わせたチューニングを行うことは企業システムにおいて必須の項目です。しかし「チューニングすべきパラメータとその最適値をどのように決定すればよいのか」、また「実際にチューニングを施すことによってどの程度効果があったのか」を把握することは意外に難しいものです。 ですが、敢えていえば答えは明瞭で、「定量的な情報収集と分析」の他にないでしょう。あらかじめ情報を収集しておけば、チューニング前後でのデータを比較することによってどのような変化が起きたのかを知ることができます。 本連載では、まずはMySQLサーバにおいて収集すべき情報を提示し、その後、それらを利用した基本的なパラメータについてのチューニング方針を紹介します。 また、今回はOSにCentOS 5.0、データベースにMySQL 5
［MySQLウォッチ］第38回 インデックスの劣化と再生
データベースは，大量のデータを格納して目的に合わせて処理するのが役割である。処理を高速化する機能として，インデックスが用意されている。インデックスは，あらかじめ検索やソート対象となる列のデータを処理しやすいように別管理するものだ。インデックスを使いこなせるかどうかで，データベース処理の良し悪し決まるといっても過言ではない。しかし，インデックスいつまでも高速ではない。その効果が，色褪せる時がやってくるのだ。 インデックスの効用 まずは，肩慣らしにインデックスの効用を確認する。テーブル「pono」は，日本郵政グループの日本郵便事業株式会社が提供している郵便番号データを格納したテーブルだ。 図1●テスト用のテーブル「pono」 mysql> show create table pono \G *************************** 1. row *****************
フツーな日常 - MySQLのTips
http://forge.mysql.com/wiki/Top10SQLPerformanceTipsというのがあったので、和訳してみる。 (11/23 追記)id:pekeqさんとsodaさんのコメントを受け一部更新 (4/27 追記と修正)id:hirose31さんの指摘を受け修正。あと元のサイトが構成変更していたので追従 クエリのパフォーマンスに関するTips(データベースのデザインとインデックスについても) EXPLAINを使ってクエリの実行プロファイルを取れ スロークエリログを使え(常に有効にしておけ！) GROUP BYを使っているか使えるなら、DISTINCTを使うな Insertのパフォーマンス バッチ処理によるINSERTとREPLACE INSERTの代りにLOAD DATAを使う LIMIT m,nは案外速くない 2000件以上のレコードに対してORDER BY RA
インデックスの基礎知識
■ インデックスとは データベースの世界で、インデックス(索引)とはテーブルに格納されているデータを 高速に取り出す為の仕組みを意味します。 インデックスを適切に使用することによってSQL文の応答時間が劇的に改善 される可能性があります。 インデックスにはB-Treeインデックスをはじめ、ビットマップインデックス、 関数インデックスなどの種類がありますが、ここでは最も一般的に使われ、かつ ほとんどのDBMSでサポートされているB-Treeインデックスについて解説します。 ※ CREATE INDEX文でオプションを指定しない場合は通常B-Treeインデックスが 作成されます。 ■ B-Treeインデックスのしくみ B-Tree(Balanced Tree)インデックスは次のようなツリー状の構造になっています。 ツリーの先頭はヘッダブロックと呼ばれています。ヘッダブロックでは、キー値の 範囲
MySQLのUsing Filesort : Bacteria.jp
週に一度か二度、Bacteriaが管理するサイトは大規模なプロモーションをすることがある。 140万通ものメール広告でもってやるわけだけど、そのレスポンスが強烈に重い。 サーバが悲鳴を上げているのがわかる。 ちょっと重すぎるよこれどうなってんのってことで、MySQLのslow_queryで分析をはじめることにした。 すると一番最初に引っかかったのが下記の事例だった。 MySQLにクエリを投げる場合、Explainして最も見たくないのがUsing file sortの文字だ。 file sortは負荷がかかると、Using Temporaryまで出てき始める。 こうなるともうお手上げで、クエリは結果を表示するためにディスクアクセスを繰り返し、速度は低下の一途をたどることになる。 file sortが発生するときは、たいてい決まっているがorder byを使うときだろう。 そりゃそ
Yahoo!のアイコン画像 - おぎろぐはてブロ
昨日の記事書いてるときに、気づいたのだけれど、www.yahoo.comのページのアイコン画像は、アイコン1個で1画像でなくて、巨大な画像に複数個配置して、その一部分を表示するようになっている。 おもしろいのでメモ。 左カラムのショートカットのアイコン http://us.i1.yimg.com/us.yimg.com/i/ww/thm/1/trough_1.7.gif メディアタイプやNEW表示、プルダウンボタンなどのアイコン http://us.js2.yimg.com/us.js.yimg.com/i/ww/sp/icons_1.3.gif http://us.i1.yimg.com/us.yimg.com/i/ww/sp/icons_1.4.gif 現時点では、バージョン違いが両方読み込まれていて、さらに、updatedやnewは単体画像としても読み込んでいて、なんか統制が取れてな
秋元@サイボウズラボ・プログラマー・ブログ: YSlow for Firebug ページのチューニングを助言してくれるFirefoxアドオン
via Ajaxian Yahoo! Developer NetworkからリリースされたYSlowは、Firefox+Firebugのアドオンとして、ページの表示速度の改善点を列挙してくれるというツールだ。 ここのところ、ウェブサイトのパフォーマンス改善で積極的に資料を公開しているYahoo!が、ツールも出してきた。今日のOSConにて発表されたもののようだ。 アドオンをインストールして任意のページを開くと、Firebugのメニューの中にYSlowが追加される。Performanceのタブには、パフォーマンスの点数(下記では「C(71)」)と、13の項目のそれぞれについてパフォーマンス対策がされているかどうかを、A～Fのグレードで表示してくれる。 それぞれの指摘をクリックすると、Yahooの解説ページに飛んで、何がパフォーマンスの障害になっているのか、何をどう直すと改善されるのか、が読め
YSlow for Firebug - おぎろぐはてブロ
ページを速くする14のルール - おぎろぐはてなで紹介した“High Performance Web Sites”のスライドなどでも触れられているYSlowというYahoo!社内ツールであったFirefox Addon が一般に公開されました。 Yahoo Developer Network これ何かっていうと、インストールすると、Firebugが拡張されて、上のスライドの 14Rules Make fewer HTTP requests Use a CDN Add an Expires header Gzip components Put CSS at the top Move JS to the bottom Avoid CSS expressions Make JS & CSS external Reduce DNS lookups Minify JS Avoid redirects
Best Practices for Speeding Up Your Web Site - Yahoo Developer Network
Best Practices for Speeding Up Your Web Site The Exceptional Performance team has identified a number of best practices for making web pages fast. The list includes 35 best practices divided into 7 categories. Minimize HTTP Requests tag: content 80% of the end-user response time is spent on the front-end. Most of this time is tied up in downloading all the components in the page: images, styleshee
qmail の配信能力を極限まで引き出す方法（ログ関連）
「syslog は I/O 負荷が高い → daemontool に移行しよう！」でも書きましたが、メール配信サービスのような用途の場合、メールサーバの配信ログってのは極めて重要。qmail の配信能力を極限まで引き出すには、様々なチューニングの中でも重要なのがログの出力。 そこで思いついたのがログの出力を RAMディスク上に出力するって方法。もちろんログの出力は daemontool 経由で。 もちろん出力したログは日時バッチでローカルディスク上にバックアップログとして保存。OS フリーズ等でメモリ上のログが失われるって可能性は許容するって要件で構築。 実際に業務で採用して速度の計測をしていたところ、 Intel(R) Xeon(TM) CPU 3.06GHz × ２、 メモリ４Ｇ （うち、RAMディスクは２Ｇ） なＨＷ環境、 net-qmail ベースにいろいろな patch を適用し
DSAS開発者の部屋:5分でできる、MySQLのメモリ関係のチューニング！
MySQLのチューニングにおいて非常に重要となるメモリ(バッファ)関連のパラメータについて、 チューニングのポイント DSASのとあるDBサーバ(実メモリ4GB)の実際の設定値 をまとめてみます。 また、必要メモリの総量の計算や限界値を越えてないかチェックしてくれるスクリプトも紹介します。 是非、参考にしてみてください！ まず最初に注意点を。 バッファには2つのタイプがあります。 グローバルバッファ スレッドバッファ グローバルバッファはmysqld全体でそのバッファが1つだけ確保されるもので、 これに対し、 スレッドバッファはスレッド(コネクション)ごとに確保されるものです。 チューニングの際にはグローバル/スレッドの違いを意識するようにしましょう。 なぜなら、スレッドバッファに多くのメモリを割り当てると、コネクションが増えたとたんにアッという間にメモリ不足になってしまうからです。 in
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
認証がかかっています
http://www.res-system.com/item/550
http://komagata.sakura.ne.jp/wiki/index.php?65536%C7%DC%C2%AE%A4%A4SQL
Firefox まとめサイト
IBM Developer
IBM Developer