クエリキャッシュは切ったほうがいいんじゃなイカ？ : DSAS開発者の部屋
KLab Advent Calendar 2011 「DSAS for Social を支える技術」の2日目は、昨日に引き続き、MySQLを骨までしゃぶるためのテクニックです。 ソーシャルゲームは一般サイトよりもDBへの更新クエリの割合が多くなりがちです。更新クエリが多いMySQLでは、通常は有益なクエリキャッシュが無益どころか有害になります。 そもそもキャッシュヒット率が低い。20%以下なんてこともザラにある しかもクエリキャッシュの更新はグローバルなロックを取得する からです。特に後者は問題です。ただの参照クエリもクエリキャッシュを更新する上に、更新クエリはクエリキャッシュの全エントリをチェックして、更新したテーブルに影響がありそうな全キャッシュをdiscardしていくためです。たとえばユーザーの行動力のようなパラメータを格納した参照も更新も多いテーブルでクエリキャッシュが有効になって
MySQL 5.5をわずか30秒足らずでコンパイルするためのテクニック
べっ・・・別にソースコードなんて自分でコンパイルしないんだからねッ！！などと言わずにまず聞いていただきたい。30秒でMySQLのコンパイルが出来るというこの事実を。最近、細々とビルド時間の短縮に取り組んでいたのだが、正直ここまで爆速になるとは思わなかった。今日はビルド時間短縮のためのテクニックを紹介するので、是非皆さんも参考にして、快適ビルド生活を送って頂きたい！！ 自己ベストは26.262秒マシンの状態や負荷の状況によって多少ビルドにかかる時間は前後してしまうのだが、これまでの自己ベストはなんと26.262秒。平均すると30秒ぐらい。以前は1分を切ることがなかったのだが、今ではなんとその半分でビルドが出来てしまう。これは純粋にmakeをするのにかかった時間であり、cmake（MySQL 5.5以降）やconfigure（MySQL 5.1以前）にかかる時間は除いてある。だがそれでも速い。
「優れたMySQL DBAを見分ける27+3の質問」に対する回答例
随分と更新が空いてしまったが、「優れたMySQL DBAを見分ける27+3の質問」に対する回答例（漢バージョン）を紹介しよう。実は質問を掲載した際「難しい！」というコメントが非常に多く、もう少し易しい質問にするべきだったかと思って次のように呟いてみたのだが・・・ 非常に心強くて安心した。さすがに日本を代表するMySQLのエキスパートである。出題のレベルは間違ってはいなかった！！ そんなわけで、回答の方に移ろう。 MySQLのサーバープロセスはいくつある？ひとつ。mysqldはシングルプロセス・マルチスレッドモデルを採用しているので、"サーバー"プロセスはひとつである。多くの場合、Linuxなどでmysqldを動かす場合には、お供にmysqld_safeも常に動いていることが多いが、mysqld_safeはサーバーではなく、mysqldのためのラッパーであるので数には含めない。 rootユー
ServersMan@VPSでMySQL InnoDB Pluginをあきらめない - SH2の日記
DTIの仮想専用サーバServersMan@VPSを借りてみました。 Entryプランはメモリが256MBでまあ足りるだろうと思っていたのですが、ServersMan@VPSではOpenVZという仮想化ソフトウェアを使っていて、なんとスワップの利用が禁止されているのだそうです。つまりなにがなんでも総メモリ使用量を256MB以下に抑える必要があります。ちょっと難しそうです。 とりあえずMySQL 5.1.45をインストールして、すべてデフォルトで起動するとこんな感じです。 # free -m total used free shared buffers cached Mem: 256 23 232 0 0 0 -/+ buffers/cache: 23 232 Swap: 0 0 0 # service mysql start Starting MySQL. SUCCESS! # free
漢(オトコ)のコンピュータ道: InnoDBでCOUNT()を扱う際の注意事項あれこれ。
InnoDBを使うとき、MyISAMと比較して度々やり玉に挙げられるポイントとして「COUNT()が遅い」というものがある。確かにInnoDBにおいて行数を弾き出すのにはテーブルスキャンが必要なのだが、そもそもMyISAMのCOUNT()が速い（テーブルの行数を保持してる）のが特殊なのであって、InnoDBが遅いわけではないのである。とはいえ、高速なCOUNT()については需要が多く、この問題には多くの人取り組んでおられるようだ。しかしながら、COUNT()のチューニングについては未だ語られていない点があるように見受けられるので、今日はCOUNT()のチューニングについて解説しようと思う。 COUNT(*)、COUNT(col)、COUNT(1)の違い基本的なことではあるが、COUNT(*)とCOUNT(col)では意味が異なるため、異なる結果が返される場合がある。COUNT(*)はフェッ
大人のためのInnoDBテーブルとの正しい付き合い方。
InnoDB関連でよくある質問のひとつに「テーブルのメンテナンスは何をすればいいんですか？」というものがある。InnoDBはMySQL 5.5でデフォルトストレージエンジンとなるため、InnoDBのテーブルメンテナンス計画を立ようと思う機会も増えることだろう。そこで、今日はInnoDBのテーブルメンテナンスの各種方法となぜそうしなければいけないかという理由を解説しようと思う。 ANALYZE TABLEテーブルメンテナンスの代名詞といえば、インデックス統計情報の更新ではなかろうか。運用を続けるうちに、知らず知らずインデックス統計情報が狂ってしまい、思うような性能が出ない。RDBMSにはそのような問題がつきものであるが、InnoDBの場合、ANALYZE TABLEは不要である。なぜなら、InnoDBが自発的に統計情報を更新するからだ。InnoDBは以下の条件に適合すると、ANALYZE T
InnoDBテーブルでインデックスを拡張するとパフォーマンスが落ちるかも from MySQL Performance Blog - stnard.jp
Extending Index for Innodb tables can hurt performance in a surprising way 多くのキーを使うクエリーのときに、よく最適化するときにインデックスを拡張する。通常は問題なく、インデックスの長さが劇的に増加しない限り、インデックスを使うクエリーは新しいインデックスの先頭を使うことができる。では、そうではない場合を見てみよう。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 CREATE TABLE `idxitest` ( `id` int(10) UNSIGNED NOT NULL AUTO_INCREMENT, `a` int(11) NOT NULL, `b` int(11) NOT NULL, PRIMARY KEY (`id`),
MySQLの自動変換を丁重にお断りするためのたった１種類の呪文 - sakaikの日々雑感～(T)編
先日の『これだけは覚えておきたい!!MySQL の６つの自動変換』 http://d.hatena.ne.jp/sakaik/20100225/mysqlautochange にはたくさんの反響をいただいた。 時にこちらの意図と違っちゃうこともあるけれどもケナゲに気を使ってくれる MySQL が、これほどに皆さんにも愛されていることが判り、MySQLファンの一人として嬉しい限りである。 さて、そのエントリの最後に、 なお、「SQLモード」を指定するとこれらの動作を変更することができる。SQLモードについては気が向いたらいつか紹介してみたい。 と書いたところ、速攻でキムラデービーの木村明治氏が補足エントリーを書いてくださった。 ○キムラデービーブログ [勝手に補足]これだけは覚えておきたい!!MySQL の６つの自動変換 http://blog.kimuradb.com/?eid=83851
やってはいけない!!MySQLに悲鳴をあげさせる10の方法
いつも「MySQLを使うときはこうするべき」という観点から記事を書いているが、今日は逆に犯してはいけない過ちをリストアップしようと思う。 1. 全てのカラムにインデックスをつけるデータベース初心者がもっともやってしまいがちな間違いはコレではないだろうか。インデックスはいい。検索がとても速くなるから。しかし、それと引き替えにインデックスは更新するときにコストがかかるし、その分多くのディスクスペースを消費する。特に更新にかかるコストは時に甚大で、該当するインデックスのページがキャッシュ上にない場合はディスクからいったんそのページを読み込まなければいけない。ディスクアクセスは動作にとても時間がかかるので、インデックスが多数、例えば全てのカラムに付いていたりすると「あれ？固まったか？」というような状態になってしまうことがあるだろう。インデックスは必要なカラムにだけつけるようにテーブルを設計しよう。
MySQLのEXPLAINを徹底解説!!
以前、MySQLを高速化する10の方法という投稿で「EXPLAINの見方についてはいずれ解説しようと思う」と書いてしまったので、今日はその公約？を果たそうと思う。 MySQLのチューニングで最も大切なのは、クエリとスキーマの最適化である。スキーマの設計は一度決めてしまうとそのテーブルを利用する全てのクエリに影響してしまうためなかなか変更することは出来ないが、クエリはそのクエリだけを書き直せば良いので変更の敷居は低い。そして遅いクエリをなくすことは、性能を大幅に向上させるための最も有効な手段である。従って、アプリケーションの性能を向上させたいなら、まず最初にクエリのチューニングを検討するべきなのである。 最適化するべきクエリはスロークエリログやクエリアナライザで見付けられるが、ではそのようなクエリが見つかった場合にはどのように最適化すればいいのか？そのためにはまず現在どのようにクエリが実行さ
mysql [paulownia.jp]
インデックス（B-treeインデックス）を使った検索では、絞られる件数が少ないほど高速になる。ユニークキーのように1レコードを特定できるインデックスならテーブルに1億レコードあっても待ち時間はほぼゼロである。 しかしインデックスの効果は、条件に一致するレコードが増えるほど減少する。例えば性別のようにデータの種類が2パターンしかないようなものは全く効果が期待できない。このようなカラムを「カーディナリティ度が低い」という。B-treeインデックスはカーディナリティ度が高いカラムに対して使うことで効果を発揮する。 MySQLはテーブルの30％以上のレコードが取得されそうだと予想するとインデックスを使わない。カーディナリティ度の低いカラムに対するwhere条件の検索では多くのレコードが取得される可能性があり、MySQLのオプティマイザはインデックスを使用しないことを選ぶ可能性が高い。 低カーディナ
ウノウラボ Unoh Labs: MySQLのチューニングのためのデータの集め方
いつの間にか会社で古株になったyamaokaです。 webアプリケーションのバックエンドにMySQLを使っている場合、 クエリ（SQL）のチューニングをする必要がありますよね。 皆さんはチューニングの計画をどのように立てていますか。 もちろん、既に明らかに重いことが想定されているページがあれば、 その処理で使われているクエリを中心にEXPLAINなどを使って解析していけばいいと思います。 でもそうではなく、全体的にクエリの見直しやチューニングを行いたい場合は 実際に実行されているクエリを確認していくという作業が必要です。 そこで使うことができる3つの方法について書きたいと思います。 遅いクエリを記録する MySQLにはスロークエリログといって、 実行に時間がかかったクエリを記録する機能が最初から付いています。 /etc/my.cnfに次のように設定を書けば実行時間が1秒を超えたクエリが出力
漢(オトコ)のコンピュータ道: モダンなMySQLの開発環境の構築方法
遅ればせながら モダンな Perl の開発環境の構築方法 モダンなPHPの開発環境の構築方法 モダンなPythonの開発環境の構築方法 モダンな Java の開発環境の構築方法 に続いてみる。MySQLは言語じゃないけど。 コンパイラ等MySQLをソースからビルドするのでなければコンパイラ等は必要ないけど、どうせアプリ開発に必要なので「MySQLなんかいつでもハックしてやるぞ！」という意気込みを示すために入れておこう。OSXならXcode、LinuxならGCC。最新のソースコードじゃないとヤダ！という粋な人にはBazaarのインストールもお勧めしたい。Bazaarは言わずと知れた分散バージョン管理システムであり、MySQL開発チームも採用している。最新のソースコードは次のコマンドでゲット可能だ。 shell> bzr branch lp:mysql-server/5.1 mysql-5.1
MySQLの照合順序：utf8_unicode_ciってなんぞ？: CodeIgniterで発火する？
前回はヴァリデートのコードをそれぞれのメソッドの頭に記述して、なんちゃって入力チェックのようなことをやった経緯を書きました。あんな実装でも変なエラーが出なくなってきたので、まあヨシとしてます。 んで、ようやく今回は検索機能の強化？について書けるかな？と考えていたんですが、どうやろうか？などと思案しながらスクリプトをいじっていると奇妙な現象？に遭遇したので、検索機能の強化はまた後回しにして今回はそれについて書きます。 結論から言うと自分がMySQLの照合順序なるものを全く理解していなかったというだけの話です。「あ～それね」「今更何言ってんの？」と言い切れる方は以下は読む必要はありません。なので以下は個人的なメモです（愚痴とも言う…ﾏﾀｶﾖ）。 まず奇妙な現象というのは以下のようなモノです。 例の五十音パッドで「た」で始まる新市町村を検索します。 伊達市 2006-03-01 大仙市 2005
「エキスパートのためのMySQL[運用+管理]トラブルシューティングガイド」発刊のおしらせ。
来たる6月12日、我が入魂の書籍が発刊される運びとなった。執筆を開始したのはすでに一年以上前であり、本ブログでも何度か「執筆中です！」といいながらなかなか発刊に至らずお待たせしてしまったのだが、しかし時間がかかってしまった分、内容には磨きがかかったと思うので期待して頂きたい。書籍のタイトルは「エキスパートのためのMySQL[運用+管理]トラブルシューティングガイド」。筆者にとって初の著書（単著）である。名前にエキスパートと冠している通り、中級〜上級者向けの一冊となっている。初心者の方は、まずMySQL 徹底入門 第2版などを先に読んでから本書を購入するといいだろう。以下もくじである。 第1章 MySQLの概要 1 MySQLとは 1-1 世界で最も有名なオープンソースのRDBMS 1-2 LAMPの"M" 1-3 History 2 MySQL Serverの種類 2-1 FOSS Exc
![「エキスパートのためのMySQL[運用+管理]トラブルシューティングガイド」発刊のおしらせ。](https://cdn-ak-scissors.b.st-hatena.com/image/square/8ba3ef9665d5ead49f8e0a53e167dbe3d842aa12/height=288;version=1;width=512/https%3A%2F%2Flh3.googleusercontent.com%2Fblogger_img_proxy%2FAJ0KDdXINpZoYs9iSYSITeihKn001zIuS3IuyadN7xqcw0-JsZxk9cHoKIXz-uWDV00HQITb-BXcJzVM_u2pYGM1lp149i7GZGPHUk-7Sx-iEGEa8o0TnPKOaTKQziG9sQg464kRvYRnsw%3Dw1200-h630-p-k-no-nu)
MySQL 5.1.47リリース - SH2の日記
出ました。今回は機能追加が1件、バグ修正が28件あります。バグ修正のうちセキュリティに関するものが3件、レプリケーションに関するものが2件となっています。 InnoDB Plugin 1.0.8 MySQL 5.1.46で1.0.7 GAとなったInnoDB Pluginですが、今回のリリースで早速バージョンアップが行われました。ざっと見たところInnoDB Pluginの新しいデータフォーマットに関するバグ修正が目立ちますので、新しいデータフォーマットを使っている場合はアップグレードした方がよいと思います。 COMPRESSEDテーブルを利用している場合、InnoDBページの分割時に無限ループにおちいることがあった (Bug#52964) プレフィックスインデックスを利用している場合、DYNAMICおよびCOMPRESSEDテーブルのデータ削除に伴ってアサーションエラーが出ることがあった
MySQL :: MySQL 8.0 リファレンスマニュアル :: 12.16 情報関数
BENCHMARK(count,expr) BENCHMARK() 関数は、式 expr を count の回数だけ繰り返し実行します。 MySQL による式の処理速度を計測する際に使用される場合もあります。 NULL や負の繰返し回数などの不適切な引数の場合、結果値は 0 または NULL です。 この使用目的は、mysql クライアント内から、クエリーの実行時間をレポートすることです。 mysql> SELECT BENCHMARK(1000000,AES_ENCRYPT('hello','goodbye')); +---------------------------------------------------+ | BENCHMARK(1000000,AES_ENCRYPT('hello','goodbye')) | +-----------------------------
知らなかった。mysql の -o オプション - sakaikの日々雑感～(T)編
mysql クライアントコマンドにはたくさんのオプションがあります*1。 その中には使ったことのないオプションもいっぱいあって、私はこの -o オプションというのを知りませんでした。 -o, --one-database Only update the default database. This is useful for skipping updates to other database in the update log. 指定したスキーマだけをターゲットにできるもののようで、更新ログをそのまま 流し込む時に特定のＤＢだけを相手にする（他はエラーになる）時に便利だと 書いてあるのですが、んー。使い出がイメージできません。。 それはともかく、今回書きたかったのはコレではなくて、、、、 こんなことがあったんですよ。 まず MySQL サーバに接続して、その際スキーマ指定を忘れたので u
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
SitePoint Blogs » JSON-P output with Rails
現場指向のレプリケーション詳説