ご指定のページが見つかりませんでした URLの変更、もしくはページが削除された可能性があります。 お手数ですが、以下のリンクから目的のページをお探しください。
KLab
ご指定のページが見つかりませんでした URLの変更、もしくはページが削除された可能性があります。 お手数ですが、以下のリンクから目的のページをお探しください。
MySQLのEXPLAINを徹底解説!!
以前、MySQLを高速化する10の方法という投稿で「EXPLAINの見方についてはいずれ解説しようと思う」と書いてしまったので、今日はその公約？を果たそうと思う。 MySQLのチューニングで最も大切なのは、クエリとスキーマの最適化である。スキーマの設計は一度決めてしまうとそのテーブルを利用する全てのクエリに影響してしまうためなかなか変更することは出来ないが、クエリはそのクエリだけを書き直せば良いので変更の敷居は低い。そして遅いクエリをなくすことは、性能を大幅に向上させるための最も有効な手段である。従って、アプリケーションの性能を向上させたいなら、まず最初にクエリのチューニングを検討するべきなのである。 最適化するべきクエリはスロークエリログやクエリアナライザで見付けられるが、ではそのようなクエリが見つかった場合にはどのように最適化すればいいのか？そのためにはまず現在どのようにクエリが実行さ
ハタさんのブログ : Q4MをPHP(PDO)で
Q4Mが無事インストールできたので、PHPから触ってみる。詳細なことは今度書く。とりあえず触りだけでも テーブル定義 drop table if exists hoge_queue; create table hoge_queue( id int not null, name varchar(25) not null ) engine=queue; こんなスクリプトをガンガン回して、監視 $conn = new PDO('mysql:host=localhost; dbname=hogetest', 'user', 'password'); $wait = $conn->prepare('SELECT queue_wait("hoge_queue", 10)'); $abort = $conn->prepare('SELECT queue_abort()'); $e = $conn->pr
Using filesort
去年ソートに関する記事を書いたが、今日はその続きである。 MySQLでEXPLAIN SELECT...を実行するとExtraフィールドでよく見かける「Using filesort」という文字列。Filesortって一体なんだろう？と思ったことはないだろうか。単刀直入に言ってFilesortの正体はクイックソートである。 クエリにORDER BYが含まれる場合、MySQLはある程度の大きさまでは全てメモリ内でクイックソートを処理する。ある程度の大きさとはsort_buffer_sizeであり、これはセッションごとに変更可能である。ソートに必要なメモリがsort_buffer_sizeより大きくなると、テンポラリファイル（テンポラリテーブルではない）が作成され、メモリとファイルを併用してクイックソートが実行される。 Filesortは全てのソート処理において実行されるわけではない。前回の記事
フツーな日常 - 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エスケープにおける「\」の取り扱い
補足 この記事は旧徳丸浩の日記からの転載です。元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2。 備忘のため転載いたしますが、この記事は2008年6月2日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり 昨日のエントリ(徳丸浩の日記 - そろそろSQLエスケープに関して一言いっとくか - SQLのエスケープ再考)は思いがけず多くの方に読んでいただいた。ありがとうございます。その中で高木浩光氏からブクマコメントを頂戴した。 \がescape用文字のDBで\のescapeが必須になる理由が明確に書かれてない。\'が与えられたとき'だけescapeすると…。自作escapeは危うい。「安全な…作り方」3版で追加の「3.失敗例」ではDBで用意されたescape機能しか推奨していない このうち、まず「\」のエスケープが必
InnoDB のパフォーマンスチューニング - MySQLカンファレンス2007 - akiyan.com 管理人メモ
http://www.mysql-ucj2007.jp/details/j25.html 木下 靖文 氏 NTTコムウェア株式会社 プロジェクト管理統括部技術SE部門 DB技術グループ （「InnoDB」は「いんのでーびー」と言うらしい...今まで「いのでーびー」と言ってました） InnoDBをなぜ使うか トランザクション コミット、ロールバック、セーブポイント 外部キー 行レベルロック オンラインバックアップ クラッシュリカバリ クラッシュリカバリ MyISAMはデータ量の増大とともに時間がかかる InnoDBはデータ量の増大との相関がない InnoDBチューニングの王道的アプローチ クエリを改善して全体的に処理効率を上げる データサイズをできるだけ小さく メモリをできるだけ多く積む コミット性能（同期書き込み） innodb_flush_log_at_trx_commit=1,0,2
ウノウラボ Unoh Labs: MySQL オペミスでデータが破損してしまった場合の復旧方法
こんにちは satoです。 オペミスで update に where句を付け忘れたり、プログラムのバグでデータが破損してしまったりした場合でも、バイナリログには更新SQLがすべて書き込まれるので、バックアップデータからオペミスが起こるまでの全てのSQLを流し込めれば、元の状態に戻すことは可能です。 •バイナリログを取っている •オンラインバックアップをとっている(mysqldumpやMySQLを止めた状態でのcpによるバックアップとバイナリログ) •バックアップ時点でのバイナリログの書き込み位置を保存している 以上のような状態でデータが壊れた時の復旧手順をまとめてみました。シナリオとして •ある1カラム email をupdateしようとしたら、間違ってwhere 句を付け忘れ 全レコードをupdateしてしまった •気がついたのが半日後 というオペミスが発生したとします 1) データベー
MySQLの高度な管理とチューニングテクニック
MySQLの高度な管理とチューニングテクニック：快速MySQLでデータベースアプリ！（11）（1/2 ページ） 本連載もついに最終回。今回はMySQLサーバの運用・管理に必要な状態監視、チューニング、バックアップ、セキュリティについて解説する。以下のテクニックを駆使すれば、MySQLをさらに安定稼働させられるだろう。 前回までは、さまざまな言語やアプリケーション、とりわけWebアプリケーションからMySQLを利用することを主眼に説明してきました。皆さんの中には、それらを応用した実用的なプログラムを考えている方もいるかと思います。そこで、今回は運用上必要となるテクニックをいくつかのトピックに分けてご紹介します。「まだまだ実用は先だ」と思われている方も、いつかくる日のためにこんなこともできるということだけでも知っておいてください。 ロギング機能と動作ステータスの取得 障害発生を防ぐための一番の
PHPとMySQLの個人的まとめ - ぱんぴーまっしぐら
Don't let me cry（右手を回して拳のつきあげ） Don't let me sigh（ 左手を回して拳のつきあげ）呪文のように唱えて（両手を頭の上でクラップジャンプ） MySQLではまったこと MySQLの文字化け 今さら何いってんのコイツとかそこ言わない。 文字コードを確認するSQL文「SHOW VARIABLES LIKE 'char%';」 MySQL4.1以降はサーバとは別にクライアントの文字コードが設定されている。 クライアント、サーバ間で違う文字コードがセットされていると、一度ucs2変換を通る。 よって、クライアント、サーバ間で違う文字コードを指定することとなり文字化けが起こる可能性がある。 PHPはmy.cnfで[mysql]、[client]を設定しようがクライアントの文字コードはビルド時に指定されたキャラクタセット(通常latin1)。 my
phpMyBackupPro - the MySQL backup tool :: Features
Here on the offcial homepage you will find all informations about phpMyBackupPro (pMBP). phpMyBackup Pro is a very easy to use, free, web-based MySQL backup application, licensed under the GNU GPL. You can create scheduled backups, manage and restore them, download or email them and a lot more! - backup of one or several databases with or without data, table structure, ... - scheduled backups with
MySQL Conference & Expo 2007 - とあるはてな社員の日記
一昨日から今日まで3日間の日程で開催されていた、MySQL Conference & Expo 2007に行ってきました。日帰り圏内どころか、自転車圏内で、こういうカンファレンスがあるのは、素晴しいです。 詳細は、随時アップされるであろうプレゼン資料と、Planet MySQLに大量の報告があります(全部英語ですけど)。 個人的に注目していたのは、Digg.com、Flickr.comとYoutube.comのDB周りアーキテクチャのセッションでした。あとは、http://www.mysqlperformaceblog.com/の人のセッションは、細かいTipsが多く、具体的にだいぶ役に立ちそうです。 というわけで、簡単に注目したセッションの内容を紹介してみます。ちなみに、内容の正確さは無保証です:P 気が向けば、もっといろいろ考察してみるかもしれません。 Technology at Di
フツーな日常 - InnoDBを使うときのパフォーマンスチューニング
ストレージエンジンとして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の最適化
限りなく眠気を誘うPHP Internalsのセッションから逃げる。こっちの 講師はMySQL.comの人。講演慣れしていて、ずっとまともでプロフェッショナルな 感じ。午前中を逃したのが惜しいが、詳しいプレゼン資料は後日公開される らしい。 DELETEのコストはかなり高い 読みだしがすごく多い場合は無効化を示すフィールドを作りUPDATEすべき、 index更新のコストが馬鹿にならないSHOW STATUSの表示結果の解析方法 起動ごとに初期化、全データベースに共通rnd と rnd_next の割合Key_reads : Key_read_requests 、ディスクから読まれた回数：総回数 この割合が1:100より悪くなったら要注意Key_write_requests:Key_writes 総書き込み要求回数：ディスクに書き込ま れた回数 キャッシュの効果などMax_used_con
MySQL/最適化/サーバパラメタ - Linux Tips
ここでは、サーバパラメタの最適化によるMySQLのチューンについて紹介する。 _ パラメタのチェック 現在の設定値を確認するには、 # mysqld --help とする。 MySQL-5.xでは、 # mysqld --verbose --help としないと、確認できなかった。 あるいは、クライアントから、 mysql> SHOW VARIABLES; でもOK。 ↑ key_buffer_size † MyISAM テーブルのインデックスを保存しておくバッファの大きさ。サーバ全体で共有される。メモリに余裕があれば、MyISAMのみのMySQL専用サーバなら、RAMの1/2、Apache などと共用なら、RAM の1/4程度とする。ただし、サイズを大きくすると、OSのページングのために、逆に遅くなることもあるので注意。 set-variable = key_buffer=256M M
DSAS開発者の部屋:5分でできる、MySQLのメモリ関係のチューニング！
MySQLのチューニングにおいて非常に重要となるメモリ(バッファ)関連のパラメータについて、 チューニングのポイント DSASのとあるDBサーバ(実メモリ4GB)の実際の設定値 をまとめてみます。 また、必要メモリの総量の計算や限界値を越えてないかチェックしてくれるスクリプトも紹介します。 是非、参考にしてみてください！ まず最初に注意点を。 バッファには2つのタイプがあります。 グローバルバッファ スレッドバッファ グローバルバッファはmysqld全体でそのバッファが1つだけ確保されるもので、 これに対し、 スレッドバッファはスレッド(コネクション)ごとに確保されるものです。 チューニングの際にはグローバル/スレッドの違いを意識するようにしましょう。 なぜなら、スレッドバッファに多くのメモリを割り当てると、コネクションが増えたとたんにアッという間にメモリ不足になってしまうからです。 in
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
InnoDB 最適log file size を計算する MySQL5.0以降| MySQL Perfor... ノウハウ [okyuu.com]
https://labs.cybozu.co.jp/blog/kazuho/archives/2007/10/innodb_warmup.php
EnterpriseZine：DeNAの人気サイトに学ぶ LAMPによるWeb-DBシステム構築/運用の極意 (前編)
kndb.jp