[ThinkIT] 第6回：query_cache_sizeの違いによるパフォーマンス比較 (1/3)MySQLサーバには、MySQLクライアントからのクエリとその実行結果をキャッシュし、次回から同じ内容のクエリが要求された場合にキャッシュから応答する、クエリキャッシュという仕組みがあります。キャッシュから応答させることによってデータベースへアクセスする負荷を軽減し、また応答速度自体の向上も狙ったものです。 デフォルト状態ではクエリキャッシュを使用しない設定になっています。以下のように現在の「クエリキャッシュに使用するメモリ量の最大値」であるquery_cache_sizeを確認してください。
MySQL 高速化メモ
●はじめに MySQLでSELECT文が遅いと感じたり、INSERT処理だけで１日かかった！なんて事ありませんか？ そんな時は本ページのメモを参考に高速化してみてください。 ちょっとした設定だけで１日かかる処理が数分で終わる（！？）なんて事も。 ぜひお試しあれ。 ●SELECT文の高速化 １．テーブルを分ける。 同じ構造のテーブルをいくつかに分割する。例えば、wordというテーブルがあるとすると、 ja_word,en_wordなど国別に分割したり、word2005,word2006など年月日で分割してみる。 ２．テーブルにインデックスを設定する。 create index インデックス名 on テーブル名 (フィールド名); 文字列の場合はインデックスに設定する文字数を指定可能。 create index インデックス名 on テーブル名(フィールド名(要素数)); 私がやってみた感じで
cles::blogのチューニング
cles::blog 平常心是道 blogs: cles::blog NP_cles() « 偽装ロボット来襲 :: やっと採録に » 2004/11/03 cles::blogのチューニング mysql tuning 259 8へぇ さすがに昨日の一件には参ってしまったのですが、最近MySQLの負荷が高すぎることは確かなので少しチューニングをしてみることにしました。 その昔、Oracleバリバリだったときにはチューニングばかり勉強したりしていた時期もあったので、チューニングで何をしなければならないかというのは大体わかっているつもりです。今回はそのときの経験を生かして、MySQLのチューニングに挑戦してみます。 † まずはボトルネック解析から まずはなぜ遅いのかという原因を絞り込みます。これはDBのチューニングに限らず全てのチューニングという作業に共通したものですよね。これをやらずにチ
はてなは自前DCの夢を見るか？ - stanaka's blog
前に自前DCは没になったという話を書いたのですが、自前DCというのは、けっこう悪くない選択肢です。 自分達でできないことは基本的に外部に頼むしかないのですが、そのノウハウをある程度以上の期間、必要とされる場合には、最終的には自分達でやったほうが、コストも抑えることができるし、ノウハウも蓄積することができます。 例えば、VPN一つ張るにしても、外部にお願いすると、初期費用がうんぬん、保守費用が月でうんぬん、と言うことになります。ですが、OpenVPNあたりを使って自前で構築してしまえば、最初は安定させるのに苦労するものの、人件費以外のコストは相当に抑えられます。 この手のものを自前で構築した場合に問題となりがちなことは、障害が発生した場合の対応ですが、はてなの場合、もともとサーバの保守はしているので、そこに監視対象が一つ増えただけ、と思えば、差分は誤差のようなものです。 そういうわけで、基本
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
