« MySQL のクエリ最適化における、もうひとつの検証方法 | メイン | MySQL (InnoDB) に直接アクセスしてタイムライン処理を高速化する話 » 2008年06月09日 フレンド・タイムライン処理の原理と実践 MySQL (InnoDB) に直接アクセスしてタイムライン処理を高速化する話に続きます。 Twitter が注目されるようになって久しい今日この頃ですが、友人の投稿を時系列に並べて表示する、というのは、Twitter に限らず Mixi の「マイミクシィ最新日記」やはてなブックマークの「お気に入り」等、ソーシャルなウェブサービスにおいては一般的な手法です。ですが、この処理 (以下「フレンド・タイムライン」と呼ぶ) は、一見簡単そうに見えて、実装には様々な困難が伴います。本記事では、「フレンド・タイムライン」を実現する、プッシュ型とプル型の二種類の手法について、その原
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
週に一度か二度、Bacteriaが管理するサイトは大規模なプロモーションをすることがある。 140万通ものメール広告でもってやるわけだけど、そのレスポンスが強烈に重い。 サーバが悲鳴を上げているのがわかる。 ちょっと重すぎるよこれどうなってんのってことで、MySQLのslow_queryで分析をはじめることにした。 すると一番最初に引っかかったのが下記の事例だった。 MySQLにクエリを投げる場合、Explainして最も見たくないのがUsing file sortの文字だ。 file sortは負荷がかかると、Using Temporaryまで出てき始める。 こうなるともうお手上げで、クエリは結果を表示するためにディスクアクセスを繰り返し、速度は低下の一途をたどることになる。 file sortが発生するときは、たいてい決まっているがorder byを使うときだろう。 そりゃそ
ストレージエンジンとしてInnoDBを使うときはMyISAMのときと触るべきポイントが違うので注意。 http://www.mysqlperformanceblog.com/files/presentations/OSCON2004-MySQL-Innodb-Performance-Optimization.pdf を読みながら取ったメモ。状況としてはRedHat AS3.0で動かしたときのDBT2*1のパフォーマンスを改善していくというもの。MySQL デフォルト状態での分析 Handler_read_nextが多い、つまりrange scanかindex scanが多すぎる slow query logで何が悪いかを引っかける 例では2秒以上処理にかかったqeuryを記録するようにしている 結果を分析 update文が遅かったけど、update文そのままではexplainできないので、
MySQL 4.1.1以降なら、SHOW SLAVE STATUSでSeconds_Behind_Masterというのが見られるそうで、これが遅延秒数の指標として使えるっぽい。 Seconds_Behind_Master This field is an indication of how “late” the slave is: When the slave SQL thread is actively running (processing updates), this field is the number of seconds that have elapsed since the timestamp of the most recent event on the master executed by that thread. When the SQL thread has cau
MySQLサーバに限らず、大量のアクセスを処理するデータベースやアプリケーションサーバ群に対して、それぞれの環境に合わせたチューニングを行うことは企業システムにおいて必須の項目です。しかし「チューニングすべきパラメータとその最適値をどのように決定すればよいのか」、また「実際にチューニングを施すことによってどの程度効果があったのか」を把握することは意外に難しいものです。 ですが、敢えていえば答えは明瞭で、「定量的な情報収集と分析」の他にないでしょう。あらかじめ情報を収集しておけば、チューニング前後でのデータを比較することによってどのような変化が起きたのかを知ることができます。 本連載では、まずはMySQLサーバにおいて収集すべき情報を提示し、その後、それらを利用した基本的なパラメータについてのチューニング方針を紹介します。 また、今回はOSにCentOS 5.0、データベースにMySQL 5
Live nude webcam chat IntroductionLive nude webcam chat has become increasingly popular as a form of online entertainment and communication. This unique platform allows individuals to connect with models in real-time, engaging in intimate experiences through video chat. With the advancements in technology and the widespread availability of high-speed internet connections, live nude webcam chat has
MySQL5.1には,大きく改良されたレプリケーション機能が搭載された。これまでのステートメント(SQL文)ベースのレプリケーションに加えて,マスタの更新結果をスレーブが反映する行ベースのレプリケーションが搭載されたのだ。レプリケーションの機能追加によって,より正確なレプリケーション処理が可能になった。 しかし,よいことばかりではない。行ベースのレプリケーションは,注意すべき点が存在する。これまでのステートメントベースのレプリケーションと同様の設計や運用では,パフォーマンスを得られない恐れがある。今回は,MySQL5.1レプリケーションの注意点を解説する。 MySQL 5.1のレプリケーション MySQl 5.1のレプリケーションには,同期方法として3つのモードが実装されている。ステートメントベースは,マスタで実行されたSQLステートメントをスレーブでも実行する方式だ。MySQL 5.0ま
前回のエントリーデータベースを用いたセッションデータ管理についてで、MySQL とメモリの関係について良く分からない部分があると書きました。 実はここに関する理解はかなり曖昧な部分があって、調査して追記します。とくにメモリ利用量について。mysqld のプロセスが利用できるメモリの上限が、32bit OS の場合は3G 程度ということは、innodb_buffer_pool_size もこの制限を受け、これについての警告が、先に紹介したリファレンスマニュアルのものという理解だけどいいのだろうかというのが1つ。 2 つ目は、この理解があっているとすると、4G 以上のクラスのメモリをつんだサーバをDB サーバとして利用する場合、64 bit OS でないとリソースの有効活用ができないか。それとも、先に書いたとおり、OS レベルのキャッシュとして利用できるから、結果としてデータファイルを読み込む
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く