さらにMySQLを高速化する7つの方法
MySQLを高速化する10の方法という記事がとても好評だったようである。記事を読んで頂いた皆さん、ありがとう。 この記事に対する便乗（？）でWeb屋のネタ帳: PostgreSQLを高速化する16のポイントという記事を書いて頂いたようだが、そちらの方もかなり人気だったようである。他人が作ったソフトウェアに改良を加えるというフリーソフトウェアやオープンソースソフトウェアの精神も基本は便乗であるので、便乗については大いに賛成したいというかむしろ取り上げてくれてありがとう！！と思うわけであるが、ここでさらに俺はこう考える。 と。 Web屋のネタ帳さんの記事では16のポイントが紹介されているが、漢（オトコ）のコンピュータ道の記事は10の方法だったのであと6つ足りない。オトコは数で勝負！！というわけで今日はネタを振り絞ってさらに7つのMySQL高速化テクニックを紹介しよう。 1. インテルコンパイラ
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
MySQLのチューニング（クエリキャッシュ）
へんじがない。ただのポンコツのようだ。 ポンコツが今日も持ち場でガンバリつつ、 楽しく生きていくための備忘録ブログ。ぬわーーっっ！！2005年7月から絶賛「更新」中！ 【この記事の所要時間 ： 約 4 分】 MySQLのチューニングにおいてクエリキャッシュは、データベースへアクセスする負荷を軽減するので、負荷が上がったときにチェックしたい項目の１つである。 MySQLのデフォルトでは、クエリキャッシュを使用しない状態になっているので注意したい。 query_cache_sizeの違いによるパフォーマンス比較 MySQLサーバには、MySQLクライアントからのクエリとその実行結果をキャッシュし、次回から同じ内容のクエリが要求された場合にキャッシュから応答する、クエリキャッシュという仕組みがあります。キャッシュから応答させることによってデータベースへアクセスする負荷を軽減し、また応答速度自体の
MySQLのパラメータチューニングを助けてくれるツール
【この記事の所要時間 ： 約 2 分】 MySQLのパラメータチューニングの参考になるツールがある。それが、「MySQLTuner」である。このツールは、MySQLを診断して、いろいろアドバイスしてくれるプログラムである。 MySQLTunerを使ってMySQLを速くする MySQLTunerはMySQLを診断して、いろいろアドバイスしてくれるプログラム。perlスクリプトで提供されているので、簡単に実行できる。なおWindowsでは動かないらしい。 MySQLTunerでMySQLをチューニング MySQLのチューニングツールとして、以前のブログで「mMeasure」というのを紹介したが、あらたに「MySQLTuner」というツールを見つけたので紹介します。このツールは、シェル上からコマンドラインとして使うツールです。 その環境に合ったパラメータを提案してくれる。あんまり手間をかけたくな
クエリ結果のキャッシュ｜MySQL｜プログラムメモ
MySQL（バージョン 4.0.1以降）にはクエリキャッシュの機能があり、これをONにするとクエリ結果をキャッシュから読み出すことが出来て高速な動作が期待できる。 ■ 1.まず現在クエリキャッシュが有効かどうかを調べる show variables like 'query_cache_%'; show variables like 'query_cache_%'; +------------------------------+---------+ | Variable_name | Value | +------------------------------+---------+ | query_cache_limit | 1048576 | | query_cache_min_res_unit | 4096 | | query_cache_size | 0 | | query_cac
MySQL :: MySQL 5.6 リファレンスマニュアル :: 8.9.3.3 クエリーキャッシュの構成
have_query_cache サーバーシステム変数は、クエリーキャッシュが使用できるかどうかを示します。 mysql> SHOW VARIABLES LIKE 'have_query_cache'; +------------------+-------+ | Variable_name | Value | +------------------+-------+ | have_query_cache | YES | +------------------+-------+ 標準 MySQL バイナリを使用している場合、クエリーキャッシュが無効にされている場合でも、この値は常に YES です。 ほかのいくつかのシステム変数は、クエリーキャッシュ操作を制御します。これらは、mysqld の起動時に、オプションファイルやコマンド行で設定できます。クエリーキャッシュシステム変数はすべて、qu
[MySQL][VP]Vertical Partitioningストレージエンジン 0.1リリース
Vertical Partitioningストレージエンジンというストレージエンジンをリリースしました。 http://launchpad.net/vpformysql このストレージエンジンは、１対１の関係にある複数のテーブルを同一のテーブルのように扱うことを可能にするものです。 これは、１対１の関係にある複数のテーブルをjoinしたviewに似ていますが、MySQLのviewとは以下の点が異なります。 ・insertできる。 ・パーティションの刈り込みが起こる。(関係のないパーティションは利用しない) Vertical Partitioningストレージエンジンは以下のような用途で利用できます。 (Vertical Partitioningテーブルを親テーブル、統合されるテーブルを子テーブルと呼びます) １．レコードサイズの大きいInnoDBテーブルのテーブルスキャンは、レコードが増え
RailsでMySQLのENUM型を使う方法 - LukeSilvia’s diary
DBのカラムで、ステータスの様なカラムを扱いたい場合、ENUM型を使いたいことが多いです。 例えばこんな感じ CREATE TABLE blog_comments( id INTEGER NOT NULL AUTO_INCREMENT, blog_id INTEGER NOT NULL, commenter VARCHAR(40) NOT NULL, content TEXT NOT NULL, status ENUM('approved','nonapproved') NOT NULL, FOREIGN KEY (blog_id) REFERENCES blogs(id), PRIMARY KEY (id) ); Railsでやる方法 RailsでENUM型を使おうと思ったら以下のようにMigrationファイルを定義すると思います。 create_comments class Crea
Rails で mysql の ENUM カラムを使用する (マルッと！)
enum-column というプラグインがあります。 これをインストールすることで、mysqlのenumカラムを使用できるようになります。 まずはインストール ./script/plugin install enum-column DBのスキーマはこんな感じでを記述します。 create_table :enumerations, :force => true do |t| t.column :severity, :enum, :limit => [:low, :medium, :high, :critical], :default => :medium t.column :color, :enum, :limit => [:red, :blue, :green, :yellow] #... end エラーチェックは、モデルに以下のように記述。 validates_columns :sev
Tony Bourke
Super Smack (8/30/05): Oops! I had to do a restore of my web content, but I forgot Super Smack, so it was gone for a few days. Sorry about that! It's back now. (5/30/05): Super Smack 1.3 is is released!. Super Smack 1.3 includes the following fixes: PostgreSQL support now builds correctly (tested with 7.4) Super Smack should now build correctly under NetBSD (tested with 2.0.2 by Simon Lundström),
Amazon Elastic Block Store(EBS)でmysqlを動かしてみたよ - shibataismの日記
Good job, Amazonということで、実際にやってみました。 詳しくは http://developer.amazonwebservices.com/connect/entry.jspa?externalID=1663&categoryID=100 を参照していただければと思いますが、日本語の方が良いという方はこちらをご参考までに。 $で始まるコマンドはクライアントのterminalから。 #で始まるコマンドはECサーバーで実行。 とりあえず、テスト目的なので、ゼロからEC2インスタンスを作るところからやっています。 インスタンス起動とポート確認 とりあえず、僕自身は一番centosが慣れているのですが、Amazonオフィシャルのイメージにcentosが無いので、rightscaleが提供しているイメージを使うことに。 詳しくは http://vividtone.seesaa.ne
レプリケーションの復旧 - omoonのブログ
サーバの構成 マスタ１台 スレーブ３台 バージョンはいずれも4.0系 mst(192.168.1.1) --+-- slv1(192.168.1.101) | +-- slv2(192.168.1.102) | +-- slv3(192.168.1.103) 状況 スレーブのうち１台（slv2）に誤って更新系クエリを発行。以降正常にレプリケーションが行われなくなっていた。 mst(192.168.1.1) --+-- slv1(192.168.1.101) | +-- slv2(192.168.1.102) <-- これがエラー | +-- slv3(192.168.1.103) データサイズはtarでアーカイブして約12GB。アーカイブ化とコピーに30分以上かかってしまう。 サービスは思いっきり稼働中のため、スナップショットをとる際のmst上のロックは許されない。 方針 正常なサーバsl
漢(オトコ)のコンピュータ道: MySQLを高速化する10の方法
ちょっとキャッチ−なタイトルをつけてしまったが、今日は独断と偏見でMySQLを高速化する方法を10個紹介しよう。MySQLサーバをチューニングするときや初期導入する場合などに参考にしてもらいたい。 1. バッファを増やす、または減らす チューニングの基本中の基本であるが、適切なバッファサイズを設定することはパフォーマンスチューニングの要である。主なバッファは次の通り。 innodb_buffer_pool_size・・・InnoDBだけを利用する場合は空きメモリの7〜8割程度を割り当てる最も重要なバッファである。余談だが、実際にはここで割り当てた値の5〜10%ぐらいを多めにメモリを使うので注意が必要だ。 key_buffer_size・・・MyISAMだけを利用する場合は、空きメモリの3割程度を割り当てるといい。残りはファイルシステムのキャッシュ用に残しておこう。 sort_buffer_
【レポート】Facebookのデータセンターに見るMySQL活用事例 - MySQLカンファレンス (1) 熱気に満ちた4日間 - MySQL Conference and Expo | エンタープライズ | マイコミジャーナル
4月14日から17日までの4日間、米カリフォルニア州サンタクララにおいて、MySQL Conference and Expo(以下、MySQLカンファレンス)が開催された。MySQL関連の最大のイベントである。セッションは有料で、日本円で10万円を超える金額にもかかわらず、参加登録者数は2,000人近くに達し※、日本からも多くのユーザーが参加していた。 ※ セッション参加のできない、展示会場のみの申し込み者も含む。 今回のMySQLカンファレンスでは、複数データセンターにまたがってMySQLを活用するような大規模事例、ペタバイト級の規模に挑戦する事例、MySQL Clusterの事例、Heartbeat + DRBDによる高可用性の事例など、さまざまな事例が発表された。とくにFacebookは、1万台のWebサーバ、800台のキャッシュサーバ(memcached)、そして1,800台のMy
hori-uchi.com: mysqldumpで文字化けしないためのメモ
ローカルの開発環境で使っていたMySQLなんですが、何も考えずデフォルトの設定で使っていたら、mysqldumpした際に、データが文字化けして、ちょっとは待ったのでメモ。 MySQLのバージョンは4.1.20。 文字化けする原因は、mysqldumpがデフォルトでは、文字コードをUTF-8で出力するようになっていて、フィールドの型がUTF-8でない場合は、自動でUTF-8に変換するためのようです。 僕が使っていたDBは文字コードについて特に何も設定していなかったので、デフォルトの文字コードであるlatin1になっていました。 なので、これもmysqldumpするとlain1 -> UTF-8な変換が自動で行われ文字化けしたということのようです。納得。 この自動変換を行わないようにすれば解決するはず。ということで調べてみると、--default-character-setというオプションを使
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
CentOS / Red Hat PHP FastCGI script For Ngnix / Lighttpd / Apache Webserver
Change MySQL Pager For Nicer Output
[ThinkIT] 第6回：query_cache_sizeの違いによるパフォーマンス比較 (1/3)
mysqlのレプリケーション