http://mysql-casual.org/2011/11/mysql-casual-advent-calendar-2011.html の6日目の記事として書かせていただきます、sugyanです。 勢いで参加表明してしまい、今日慌てて久しぶりにMySQLを触りました。 MySQLでFizzBuzz ストアドプロシージャって使ったこと無かったので初めて触ってみました。 DROP PROCEDURE IF EXISTS FizzBuzz; delimiter // CREATE PROCEDURE FizzBuzz(n INT) BEGIN DECLARE i INT DEFAULT 1; WHILE i <= n DO SELECT CASE WHEN i % 3 = 0 AND i % 5 = 0 THEN 'FizzBuzz' WHEN i % 5 = 0 THEN 'Buzz'
■ このような場合に参考にして下さい MySQLのクライアントソフト(mysql,PHP,Perl他)からMySQLサーバーに接続しようとすると 「Can't connect to local MySQL server through socket '/tmp/mysql.sock'」 のようなエラーが出て接続に失敗する。 ■ 対処方法の前に まずはじめに、エラーメッセージは次の意味を持ちます。 「ソケット'/tmp/mysql.sock'を通じてローカルのMySQLサーバーに接続することが出来ません」 ソケットとはプロセスやネットワーク間の通信機構のことで、MySQLではこのソケットを通じて サーバーとクライアントとが接続されます。ソケットというとポート番号を指定して利用する方法が 思い浮かびますが、ここでは/tmp/mysql.sockというファイルが出てきています。 これはUNIXド
しわっす！DBA 兼オペレーションエンジニア兼タスクマネージャやってる riywo です。何のネタを書こうかなぁと考えたのですが、正直ネタを仕込む時間もなかったので僕がいつもやってることをさらっと紹介するということで勘弁して下さい＞＜ MySQL がおかしい！ 03:14 hidek: なんかエラー出まくってるんだけど！ 03:14 zigorou: MySQL と通信してるとこっぽい 03:15 riywo: 見ます こんなやりとりは皆さん日常茶飯事ですよね？ね？ね？こんな時に、DB に責任を持つものとして真っ先に対応するのが僕らの仕事です。でも、じゃあ具体的にこのあと何をしましょう？既にサービスはエラーだらけで一刻を争う状態です。 (対応開始) まずはエラーメッセージ 今回の様な場合はアプリのエラーログにどばっと MySQL に関するエラーが出ているでしょう。まずはそれを見ることが始ま
訳あって、Ruby on RailsでMySQLに画像を格納し使う実験をした。 migrationでの指定 画像を格納するカラムは migration では binary を指定します。ただし、そのままでは 64Kbyteまでしか格納出来ない blob型になってしまいます。これを mediumblob型にするには、 migrationファイルで :limit => (16*1024*1024 - 1) を指定します。 def self.up create_table :table_name do |t| t.binary :column_name, :limit => (16*1024*1024 - 1) t.timestamps end endネットを検索すると、mediumblob指定の為に execute でMySQLのSQL文を書くような記事が見つかりますが、そんな面倒はいりません
いろいろな本からメモってきたメモのメモ。出典を書いておくのを忘れた。思い出し次第補完するかも。 deleteのコストは高いので、無効化を示すフィールドを作ってupdateすべき slow query logに要注意 多くのエントリでほとんどのフィールドが同じ値を持つ場合はインデックスの効果が小さい →複合インデックスの効果が大きい 複合インデックスは指定の順番が大切。AとBという指定の場合、A単独でもインデックスの効果がある。逆は真でない。 インデックスが使われる場面は フィールド値を定数と比較するとき (where name = 'hogehoge') フィールド値でJOINするとき (where a.name = b.name) フィールド値の範囲を求めるとき (<,>,between) LIKE句が文字列から始まるとき (where name like 'hoge%') min(),
自分のプログラミング脳をプログラムにして、いつかプログラミングから脱出してやるぞっ！とか夢見ながら、日々プログラム作っていく 百野 貴博 の日記です！今は、屋号『百蔵。』として、Silverlight・WPFを追跡中です！ (2007/09/30) 追記 2010-08-12 今回のエントリですが、「漢のコンピューター道 － Using filesort」で既に解説されていました・・・。 しかも、「漢のコンピューター道」さんの方が分かりやすいっ うわぁぁぁん｡゜（ﾟ´Д｀ﾟ）ﾉ ---- 帰宅してからBlog書こうと思っていたら、さっそく帰宅後の仕事でハマってしまってBlogが中断してしまいました、、、 いけませんね！ というわけで、日中の仕事の中でもBlogのネタを溜めるようにして頑張ります！ さて、今日はMySQLのチューニングネタです！ mysql のSQLをチューニングしていて、E
Linux-DBシステム構築運用入門をさらに読んでいる。前回は主に Chapter 8 を読んだ内容をメモったが今回は Chapter 9 の内容。 INSERT とインデックス インデックスが多いと INSERT の性能が落ちる、という話題はなんとなく見聞きしていたが、何故性能が落ちるのかについてはわかっていなかった。詳しくは Linux-DBシステム構築運用入門 P210 の図を見てもらうとして*1、ランダム INSERT よりも昇順 INSERT のほうがインデックスのリーフブロックの仕様効率が良い == インデックスのサイズが小さくなる == バッファキャッシュに載りやすくなる == I/O が減る、というのは知らなかったしとても勉強になった。インデックスを更新するために INSERT でもディスクから読み込みが発生する、というのも知らなかった。 クラスタインデックスとランダム I
実践ハイパフォーマンスMySQL 第2版とLinux-DBシステム構築運用入門を読んで、 MySQL のインデックスについて勉強しなおしている。理解が曖昧だった部分の知識を深められたり、自分の間違いに気づけたりして、とても収穫が多い。 フルテーブルスキャンとフルインデックススキャン Linux-DBシステム構築運用入門 P185 に書いてあるケース。インデックスを利用してても対象レコード数が多いとランダムI/Oが大量に発生して遅くなる。読むべきレコード数が多いのならばフルテーブルスキャンのほうがI/O一回で多くのブロックを読み込めるので速い。 IGNORE INDEX ヒントを与えてパフォーマンスを改善するという例があった。 マルチカラムインデックスと範囲検索 SELECT * FROM users WHERE a = ? AND b >= ? and (c IS NULL OR c >=
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
pager, –safe-updates mysql でクエリの結果を表示する pager には “less -S” がおすすめですが、すこし古い less だと、UTF-8 の処理がいまいちだったりするので、新しい less (Version 406 以降)を使うのがよいでしょう。 また、事故を防ぐために、つねに–safe-updatesオプションを使うのは良い考えです。 そうすると、コマンドラインが % mysql -h localhost -u username –password=secret \ –pager=”/some/where/less-408 -S” \ –default-character-set=utf8 \ –safe-updates dbname のように長くなるので、シェルの alias/function に登録するなどしておきます。 まあこのあ
long_query_time = 0.5 とか閾値を小さめにしてもスロークエリが出なくなったけど、CPU(user)使用率高いとか、なんか足引っ張ってるクエリがあるっぽいなぁという場合のお話です。 「実録」の通り、現在絶賛進行中ですので、逐次動きがあったら書き足していくつもりです。 「あれを見た方がいい」とか「これをあーした方がいい」とかあれば、コメントかTwitterで @hirose31 までお知らせいただけるとうれしいです！ 使用しているのは、MySQL 5.1.41 です。 前提: サーバーリソースのグラフ GangliaでもCactiでもMuninでもなんでもいいんですが、サーバリソースのグラフ化は必須です。チューニングした際の効果測定や、そろそろリソース食い潰してやばいとかの予測にも使えます。 自分はDBサーバの場合このあたりをグラフ化してます。 CPU使用率 (user,
追記: rehash(auto-rehashも含む)すると、SQL文の補完(seleでタブ打鍵とか)が効かなくなるよと、はす向かいの人に教えてもらいました。 個人的には、SQLは「mysql> help select」とかでオンラインヘルプがびょっと出るので、スキーマの補完ができるんならSQLの補完はとりあえずあきらめてもいいかなと思っています。 常々、テーブル名とか補完できるといいなーと思っていたので、ボロっときいてみたら教えてもらいました。あざーーーーっす！ id:mikihoshi++ id:tokuhirom++ id:precuredaisuki++ おかげで効率が300%上がりました。(Benchmark::Stopwatchで計測) http://dev.mysql.com/doc/refman/5.1/en/mysql-command-options.html#option
先日の『これだけは覚えておきたい!!MySQL の６つの自動変換』 http://d.hatena.ne.jp/sakaik/20100225/mysqlautochange にはたくさんの反響をいただいた。 時にこちらの意図と違っちゃうこともあるけれどもケナゲに気を使ってくれる MySQL が、これほどに皆さんにも愛されていることが判り、MySQLファンの一人として嬉しい限りである。 さて、そのエントリの最後に、 なお、「SQLモード」を指定するとこれらの動作を変更することができる。SQLモードについては気が向いたらいつか紹介してみたい。 と書いたところ、速攻でキムラデービーの木村明治氏が補足エントリーを書いてくださった。 ○キムラデービーブログ [勝手に補足]これだけは覚えておきたい!!MySQL の６つの自動変換 http://blog.kimuradb.com/?eid=83851
今までマニュアルを斜め読みした程度で「MySQL 5.1 から使えるようになったパーティショニング。便利そうだな」などと思っていたのですが、このたび実際に使いたいシーンが出てきたので、利用を前提に調べてみました。 そしたら、ハマることハマること。やりたいことは、日付カラムで１日ごとのパーティションにしたいだけだったのですが（向こう２年分くらいパーティション作っておいて、運用で「古いパーティション削除→新しいのを追加」でいいかなと考えていました）、これができない。 ハマりの原因は「パーティショニングの条件は、プライマリーキーの一部でなければならない」という制約。 http://dev.mysql.com/doc/refman/5.1/ja/partitioning-limitations.html 今回使用を検討したテーブルはプライマリーキーが重要だったので、 CREATE TABLE pt
2009年10月28日09:33 MySQL MySQLでインデックスを使って高速化するならCovering Indexが使えそう Linux-DB システム構築/運用入門 (DB Magazine SELECTION) 著者：松信 嘉範 販売元：翔泳社 発売日：2009-09-17 おすすめ度： クチコミを見る 最近、この本を読んでいます。非常に面白いし、参考になります〜。中でもインデックスについての記事が特に興味深かったので簡単にまとめてみます。 前提 ・インデックスは検索性能には効果があるが、更新性能は落ちてしまう ・MyISAM と InnoDB ではインデックスの構造が違う ・インデックスは B+Tree インデックスと呼ばれ、ルート、ブランチ、リーフの階層構造になっている ・インデックスはソートされた状態で作成されている まずは MyISAM と InnoDB でのインデックス
ソーシャルゲーム開発者なら知っておきたい MySQL INDEX + EXPLAIN入門 広く浅くを担当してます、ota です。 技術ブログ第一回から早速流用スライドで申し訳ありませんが、社内勉強会資料として作成した「MySQL INDEX + EXPLAIN入門」です。 当社でもソーシャルゲームの開発を行っていますが、このような大量のデータを使用する・クエリの速度が求められる場合にインデックスは大変重要です。 インデックスの有効な利用にはDB設計者だけではなくプログラマにもある程度の知識が最低限必要となりますが、インデックスについての初心者向け資料があまりないようです。 このスライドではプログラマに知っておいて欲しい以下の基本的な点をまとめました。 INDEXを使用する時に気をつけること WHERE句 !=、<>はインデックスが使用できない WHERE句の全てのANDにかかっていないイン
MySQL 5.1で追加されたメジャーな機能の影に隠れた、地味だが便利な改善がある。それがスロークエリログに関する仕様である。MySQL 5.0まではスロークエリログは1秒未満のクエリを捕捉することが出来なかった。が、MySQL 5.1では1マイクロ秒までのクエリを記録できるようになっている。従って、0.5秒かかるけど大量に実行されてパフォーマンスに大きな影響を与えている！というようなクエリの発見が出来るようになった。1秒未満のクエリを追跡したい場合、例えば以下のような設定をする。 [mysqld] slow_query_log=ON slow_query_log_file=mysql-slow.log long_query_time=0.1 MySQL 5.0まではlog_slow_queryというオプションだったのが、MySQL 5.1ではslow_query_logというオプション名
書こうと思ったときに少しでも記事書いたほうがよいと思い、とりあえず書いてみる。言葉にしてまとめていくこと大事。 いつも通り流れに任せて書くので、多分整理されてないかもしれない。。間違ってる箇所があったら指摘お願いします。 今回はmysqlのチューニング＋スレッドの話です。 スレッドの基本的なチューニング my.cnfとかでmax_connection変数ってのがありますが、maxってのがついているおかげで、この値を500とか1000にすれば、その分だけmysqlが処理を行ってくれると思っちゃったりするかもしれない。多分昔の自分もそうだった気がする気がする。最大って言うぐらいだから、この値を設定しておけば問題ないみたいな。 でも、基本的にmax_connectionをいくら高めても、一秒間に処理できるクエリ（qps）はそこまで伸びない。多分、CPU利用率余ってたり、スレッド数にムラがあるのが
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く