前書いた書きかけのメモを発見したので加筆して載せてみます。ちなみにこの話はMysql(InnoDB)利用時限定です。 モデルのcountメソッドは SELECT count(*) AS count_all FROM `blogs` のようなSQL文を発行します。このようなSQL文では、基本的に主キーインデックスによる全索引検索が行われます。通常、インデックスだけを読み込む全索引検索のほうが、テーブルだけを読み込む全表検索よりもI/O回数が少なくなるため高速になりますが、InnoDBの主キーインデックスは他の列値と直結している仕様で(この場合は)余計な列値を読み込むことになるため、あまり高速になりません。主キー以外のインデックスを利用した方が高速になるようです。 実際に試してみた rails2.3.2(たぶん), mysql5.0.77で試しました。 適当なrailsプロジェクトを作成し、s
I’m happy to announce the release of MySQL Ruby bindings version 2.8.1 This release is based on my GitHub fork from original Kevin Williams work. For those who are not aware, Kevin’s gem is a Gem package of tmtm mysql-ruby bindings at RubyForge Changes This started to improve GCC support, but it ended with a take over and better packing to improve both Windows support and Ruby 1.9 compatibility. Y
前回の続き http://b.ruyaka.com/2009/07/06/ruby19-gem-install-mysql-ではまる/ なんかgem install mysqlでMySQL/Rubyはインスートルできたんですが、 どうやらMySQL/Rubyがruby1.9の「M17N」に対応していない模様。 おかげて、データベースから取り出した文字列は全て「ASCII-8BIT」になってしまいます。 マルチバイト文字列を入れるとASCII-8BITとUTF-8がぶつかりエラーが発生します。 「incompatible character encodings: UTF-8 and ASCII-8BIT」 ほんと困りました。 調べてみたところ解決方法は2通り発見。 ① MySQL/Rubyではなく、M17Nに対応しているRuby/MySQLを入れる (ややこしい) ② Rails上で「for
By Ilya Grigorik on October 27, 2008 Late last week Rails core team announced the release of Rails 2.2RC1, which amongst other things slips in 'thread safety' and an implementation of a connection pool for our beloved ActiveRecord. Pratik Naik and Charles Nutter have both covered the implications of these contributions, but the executive summary is as follows: single ruby process (mongrel), plus m
komagataです。 Webアプリケーションのパフォーマンスの大半はデータベース、特にインデックスの使われ方にかかっている気がします。 仕事でもMySQLをよく使いますが、MySQLでは1テーブルに付き1インデックスしか使われません。PostgreSQLなどと比べてそのことが気になってMySQLでのパフォーマンスチューニングに全く自信が持てませんでした。 オライリーの実践ハイパフォーマンスMySQLには下記のように書かれています。 実際、UNIONを除き、MySQLでは、1つのクエリを実行するとき、1つのテーブルに付き1つのインデックスしか使用できない。この事実は、繰り返し述べるに値するほど重要である。「MySQLでは、1つのクエリを実行するとき、1つのテーブルにつき1つのインデックスしか使用できないのである。」 また、その制約を考えたクエリの書き方として下記の様に書いてあります。 my
2007年5月31日10:53 Tom-Adelstein、Bill-Lubanovic(2007年5月29日(火)) ファイルやディレクトリのバックアップは比較的簡単だが、データベースのバックアップとなると、いくつか特別な工夫を施す必要がある。ここではMySQLを取り上げているが、同じ原理はPostgreSQLやその他のリレーショナルデータベースにもあてはまる。 本稿は、最近O’Reillyから出版された書籍『 Linux System Administration 』の抜粋。 MySQLサーバを休みなく稼働させ続ける必要がないなら、以下に示すような圧縮なしのオフラインバックアップ手法が手っとり早い。 MySQLサーバを停止させる。 # /etc/init.d/mysqld stop MySQLのデータファイルおよびディレクトリをコピーする。例えば、MySQLのデータディレクトリ/var
限りなく眠気を誘う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
昨日のmysqlarに、『恋とハックはアジャイルが命!』で有名なかずひこさんがpatchを書いて下さり、かつiar (Interactive ActiveRecord) というキャッチーな名前をつけてくれました。名前重要! MySQLじゃないと動かないかなー、と思ってたんですが、adapter差し替えただけで他でも普通に動くよ!というわけでsqliteやpostgresqlなんかでも動きます。他にもfirebird sqlserverでも動くかも。 起動は iar -a sqlite -t db/development.db なんかで。特にsqliteの対話インターフェイスは貧弱なのでかなり嬉しいかも。ソースは http://rails2u.com/misc/iar.txt に置いておきました。 で、ちょっとした irb tips。通常 irb では戻り値のinspectした値を表示してく
(追記) この問題について、原因はRubyの側にあるのではないかと考えています。特定の条件下でTCPSocket#flushを実行すると、スレッドが停止したまま処理が戻ってこなくなります。以下の投稿で、Railsを使わず再現する方法を説明しました。 http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-list/43356 (追記おわり) 開発サーバが翌日になるとデッドロックする、という現象が続いていて悩みました。 解決方法は、MongrelのFAQに上がっていました。 http://mongrel.rubyforge.org/faq.html Q: Mongrel stops working if it’s left alone for a long time. If you find that Mongrel stops work
MySQLのチューニングにおいて非常に重要となるメモリ(バッファ)関連のパラメータについて、 チューニングのポイント DSASのとあるDBサーバ(実メモリ4GB)の実際の設定値 をまとめてみます。 また、必要メモリの総量の計算や限界値を越えてないかチェックしてくれるスクリプトも紹介します。 是非、参考にしてみてください! まず最初に注意点を。 バッファには2つのタイプがあります。 グローバルバッファ スレッドバッファ グローバルバッファはmysqld全体でそのバッファが1つだけ確保されるもので、 これに対し、 スレッドバッファはスレッド(コネクション)ごとに確保されるものです。 チューニングの際にはグローバル/スレッドの違いを意識するようにしましょう。 なぜなら、スレッドバッファに多くのメモリを割り当てると、コネクションが増えたとたんにアッという間にメモリ不足になってしまうからです。 in
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
The MySQL cheat sheet is designed to act as a reminder and reference sheet, listing useful information about MySQL. It includes a list of the available functions in MySQL, as well as data types. It also includes a list of MySQL functions available in PHP, and a list of useful sample queries to select data from a database. A description of what is on the cheat sheet follows, or if you are impatient
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く