タグ

OptimizeとMySQLに関するk_37toのブックマーク (6)

  • kndb.jp

    This domain may be for sale!

  • Re: MySQL最適化のミニtips - 日向夏特殊応援部隊

    元ネタ: http://labs.unoh.net/2007/07/mysqltips.html あまり具体的じゃないので、僕の考えとか。 正しいかどうかは各自の状況だとか実際試すべきなんだけど、参考になれば。 MyISAM、InnoDBなどテーブルタイプ 僕は断然InnoDB派です。 ただ仰るとおり、ログるだけのテーブルとかならMyISAMでもいいとは思うけど。 トランザクションやロック処理などが必要ない場合など、MyISAM形式にも良いところはあるので検討してみる価値はあるかもしれません。 これだけの指摘だとちょっと微妙な気がするです。 MyISAMの使いどころってのは、 ピンで他とリレーションが無い単純追記系のテーブル リレーションがあり、同一トランザクション内での更新系クエリが存在する場合は、トランザクションが期待通りに動かないので、基的にはInnoDBと混在させるべきではない

    Re: MySQL最適化のミニtips - 日向夏特殊応援部隊
  • DSAS開発者の部屋:5分でできる、MySQLのメモリ関係のチューニング!

    MySQLのチューニングにおいて非常に重要となるメモリ(バッファ)関連のパラメータについて、 チューニングのポイント DSASのとあるDBサーバ(実メモリ4GB)の実際の設定値 をまとめてみます。 また、必要メモリの総量の計算や限界値を越えてないかチェックしてくれるスクリプトも紹介します。 是非、参考にしてみてください! まず最初に注意点を。 バッファには2つのタイプがあります。 グローバルバッファ スレッドバッファ グローバルバッファはmysqld全体でそのバッファが1つだけ確保されるもので、 これに対し、 スレッドバッファはスレッド(コネクション)ごとに確保されるものです。 チューニングの際にはグローバル/スレッドの違いを意識するようにしましょう。 なぜなら、スレッドバッファに多くのメモリを割り当てると、コネクションが増えたとたんにアッという間にメモリ不足になってしまうからです。 in

    DSAS開発者の部屋:5分でできる、MySQLのメモリ関係のチューニング!
  • 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

    k_37to
    k_37to 2006/12/17
    2001年の記事、今でも十分役に立ちそう
  • Using filesortにORDER BY NULL - Enjoy*Study

    巨大なテーブルを結合し、テーブルをまたいだ複数キーでGROUP BYするSQLを書いてEXPLAINで実行計画を確認したところ、見たく無いものが出てしまいます。 Using temporary; Using filesort テーブル結合自体はINDEXを使えているようですが(EXPLAINの結果から)、GROUP BYは、テーブルまたいてしまっているので、INDEXが使えていないのかな、、なので「Using temporary」はしょうが無いと思ったけれども、「Using filesort」が出るのが良くわかりません。 GROUP BYって、内部的にソートされるのが当然なのか!?って思ったけれども、どうもデフォルトの動作でGROUP BYの場合にソートが行われてしまう模様。 MySQL 4.1 リファレンスマニュアル :: 5.2.1 EXPLAIN 構文(SELECT に関する情報の取

    Using filesortにORDER BY NULL - Enjoy*Study
  • MySQLメモ (Nega Diary)

    Nega Diary 人生とは記憶の蓄積。日々の記録とは、日々の行動・思考を書き記し、自分の存在を確かめる行為。 ちょっと古いけど、スラドの記事。 DELETEのコストはかなり高い 読みだしがすごく多い場合は無効化を示すフィールドを作りUPDATEすべき、 index更新のコストが馬鹿にならない SHOW STATUSの表示結果の解析方法 起動ごとに初期化、全データベースに共通 rnd と rnd_next の割合 Key_reads : Key_read_requests 、ディスクから読まれた回数:総回数 この割合が1:100より悪くなったら要注意 Key_write_requests:Key_writes 総書き込み要求回数:ディスクに書き込ま れた回数 キャッシュの効果など Max_used_connections: 最大同時接続数 Not_flushed_*

  • 1