InnoDBのREPEATABLE READにおけるLocking Readについての注意点

本日は、MySQL Casual Advent Calendar 2013の20日目である。というわけでカジュアルに小ネタを紹介しよう。

知って得するInnoDBセカンダリインデックス活用術！

InnoDBはクラスタインデックスという構造になっている。今日はクラスタインデックスがどういうことかということを、皆さんに理解して頂きたい。もっとも理解して頂きたいポイントは「セカンダリインデックスのリーフノードには主キーの値が含まれている」ということだ。

大人のためのInnoDBテーブルとの正しい付き合い方。

InnoDB関連でよくある質問のひとつに「テーブルのメンテナンスは何をすればいいんですか？」というものがある。InnoDBはMySQL 5.5でデフォルトストレージエンジンとなるため、InnoDBのテーブルメンテナンス計画を立ようと思う機会も増えることだろう。そこで、今日はInnoDBのテーブルメンテナンスの各種方法となぜそうしなければいけないかという理由を解説しようと思う。

たった3秒でInnoDBのデータローディングが快適になるライフハック

MySQLに限った話ではないが、データベース管理システムに大量のデータを投入するのは時間が掛かり大変苦痛を伴う作業である。劇的に効能があるわけではないが、MySQLを利用しているとき、特にInnoDBを使っている場合にはデータの投入を高速化するためにいくつかテクニックがあるので紹介しよう。皆さんの作業時間が短縮され、少しでも早く帰路に着いたりサービスインさせたりという形でお役に立てれば幸いである。ちなみに、タイトルはネタであるのだが、もし本当に3秒で以下の全ての設定を行えた人が居たら教えて頂きたい！

InnoDB Pluginことはじめ。快適ストレージエンジン生活はじまる！

MySQL 5.1.38からMySQL本体にInnoDB Pluginバンドルされている。一部の先駆的なユーザー以外に、「InnoDB使ってますよ！」もしくは「検証してるよ！」という話をあまり聞かない。そもそもであるが、InnoDB Pluginってなんぞ？！という人が多いんではないかと思うのだが、実際はどうなのだろう？現在はRC版（リリース候補版）という位置づけのInnoDB Pluginであるが、一部影響度の高いバグが残っていたりしてGA版ほどの安定性は求められないものの、ほとんど実用に耐えうる品質になっているといえる。そんなわけで、今日は改めてInnoDB Pluginの使い方・使いどころについて説明するので、ぜひ皆さんの手でInnoDB Pluginを評価してみて頂きたい。

InnoDBでCOUNT()を扱う際の注意事項あれこれ。

InnoDBを使うとき、MyISAMと比較して度々やり玉に挙げられるポイントとして「COUNT()が遅い」というものがある。確かにInnoDBにおいて行数を弾き出すのにはテーブルスキャンが必要なのだが、そもそもMyISAMのCOUNT()が速い（テーブルの行数を保持してる）のが特殊なのであって、InnoDBが遅いわけではないのである。とはいえ、高速なCOUNT()については需要が多く、この問題には多くの人取り組んでおられるようだ。しかしながら、COUNT()のチューニングについては未だ語られていない点があるように見受けられるので、今日はCOUNT()のチューニングについて解説しようと思う。

違いが分かるエンジニアのためのMySQL/InnoDB/ZFSチューニング！

明けましておめでとうございます。今年もコンピューター道に邁進して参りますのでよろしくお願いします！

さて、今年一発目のネタはMySQL利用時におけるZFSのチューニングについて取り上げようと思う。Solarisに搭載されている機能の中でも最も注目度の高いものの一つであるZFSであるが、MySQLのバックエンドとしてはあまり利用されていないように思う。（そもそもSolarisのユーザー数自体がそれほど多くないという話もあるが。）ZFSは優れたファイルシステムであり、ファイルシステム自体にスナップショット機能が搭載されていたり容量の限界に先が見えない（充分すぎるほど余裕がある）といった管理上のメリットがあり、DBAにとっては垂涎のファイルシステムであると言える。（Linuxで利用出来ないのが難点だが、ZFSを使うためにSolarisを使うのもアリだろう。）

MySQL利用時におけるZFSのチューニングに関する日本語の記事は殆ど見かけない。しかし世界は広い。英語による記事ならば秀逸なものがある。そこで、今日は元サン・マイクロシステムズのパフォーマンス・エンジニアであるNeelakanth Nadgir氏によるZFSチューニングの解説記事を翻訳して紹介したいと思う。（翻訳することについては本人の了承済みである。氏は残念ながら昨年サンを去ってしまったが、翻訳を快諾してくれたことを感謝すると共に今後の活躍を祈りたい！）

原文：MySQL Innodb ZFS Best Practices

MySQLバックアップ頂上決戦！！ LVMスナップショット vs InnoDB Hot Backup

先日のMyNAのイベントにて、「InnoDB Hot Backup（もしくはXtra Backup）のようなツールとLVM等でスナップショットを取るのはどちらが最強のバックアップたり得るか？」という感じの内容の議論がなされていたのだが、確かにこれは答えるのが難しい永遠のテーマである。永遠のテーマだからこそ漢のロマンがある！！というわけで、今日はそれぞれのバックアップ方法について仕組みを説明しつつ私の見解を述べたいと思う。（見解≠結論ではない点には注意して頂きたい。結論を出すのは貴方なのだから！！）

オトコの近況 - ブログ停滞中のワケ

最近めっきりとブログの更新が遠のいている。

ついにネタ切れか？！

力尽きたか？！

中二病完治か？！

などという心配はしないで頂きたい。至って快調にマイペースで筆を進める毎日を送っている。ただしブログにではなくMySQL関連の書籍として。ブログは書籍の執筆が完了してから本格的に再開しようと思うので、その際にはまた是非お付き合い頂きたい。書籍も頑張って書いているので是非よろしくお願いしたい。

今書いてるのはこんな内容のものだ。原稿からプチ抜粋。

クエリキャッシュのヒット率はどのように計算すれば良いのでしょうか？ここで改めて説明するために、上の一覧ではクエリキャッシュについては敢えて省略しましたが、クエリキャッシュのヒット率は次の計算式で求めることが可能です。

Qcache_hits / (Qcache_hits + Com_select)

Qcache_hitsは文字通り、クエリキャッシュにヒットして、キャッシュからクライアントへ結果が送信された回数です。キャッシュミスが発生すると、MySQL ServerはSELECT文を実行してテーブルに対してクエリを行い、その際にCom_selectをカウントアップします。つまり、クエリキャッシュが有効になっている場合は、Com_selectがキャッシュミスをした回数を表すのです。SELECTを実行して結果を取得すると、クエリキャッシュへ結果がキャッシュされる場合と、結果セットが大きすぎる理由などによってキャッシュされない場合があります。キャッシュされた場合はQcache_insertsがカウントアップされ、されなかった場合にはQcache_not_cachedがカウントアップされます。従って、次のような関係式が成り立つでしょう。

Com_select ≒ Qcache_inserts + Qcache_not_cached

これを上記の式に代入すると、クエリキャッシュのヒット率は次のように変形することが可能です。

Qcache_hits / (Qcache_hits + Qcache_inserts + Qcache_not_cached)

Com_selectは離れた位置にあるので、Qcache_%だけを見てヒット率が判断できるこの式を用いると便利でしょう。この式ならば「SHOW GLOBAL STATUS LIKE 'Qcache%'」というコマンドでステータス変数を表示するだけで事足ります。

本のタイトルは「金利0無利息キャッシング - クエリキャッシュできます！！」ではなく（ってかそのタイトルはパクリだよ！＞俺）もっと広い範囲の内容をカバーした書籍になる予定なのでタイトルもそれに相応しいものになるだろう。タイトルは書き終えたら発表します。

書籍は書いていてもPlanet MySQLのチェックは欠かさないのが日本男児たるものの嗜みだが、ちょうど本日sh2氏による魂の籠もった検証結果報告のエントリが投稿されているので以下に紹介させて頂く。

MySQL InnoDB Pluginのデータ圧縮機能
http://d.hatena.ne.jp/sh2/20090628

InnoDB Pluginとは、MySQLに組み込まれているInnoDBを置き換えるストレージエンジンで、デフォルトのものにはない特徴を備えている。sh2氏によって検証が行われているデータ圧縮機能はInnoDB Pluginだけで使える拡張機能である。だからアナタが使ってるInnoDBでデータ圧縮が出来なくても不具合ではないので焦らないように！InnoDB Pluginを利用するには、以下のページからダウンロードしてインストールする必要があるのでチャレンジャーな人達は試して頂きたい。
http://www.innodb.com/products/innodb_plugin/download/

インストール方法はこちら。
http://www.innodb.com/doc/innodb_plugin-1.0/innodb-plugin-installation.html

sh2氏によると、Wikipediaのデータをおよそ半分に圧縮できたらしい。なんと、InnoDB Pluginを使えばデータ量が約半分になるということである。これはかなりの節約になるだろう。

ところで、とても偶然なタイミングなのだが、IBMの中の人もDB2の圧縮機能の検証をされていたようである。

ClubDB2 場外ブログ: 圧縮機能で遊んでみる
http://clubdb2.blogspot.com/2009/06/blog-post_27.html

こちらも圧縮した結果は半分程度だそうだ。

つまりInnoDB PluginとDB2 V9.xの圧縮機能は互角？！高価な商用データベースであるDB2と肩を並べるぐらいの圧縮率というのは、InnoDB Pluginの圧縮機能はかなり優秀だと言っていいのではないだろうか。

あの漢（オトコ）が・・・ブログを始めた!!

現在、MySQL Performance Blogおよびその運営会社であるPerconaで活躍中の木下氏が、なんと日本語でブログを始めた。

ＤＢ改造屋雑記

木下氏はInnoDBのスペシャリストであり、おそらく実力はアジア一だろう。しかもレプリケーションなど、MySQLの他の機能に関しては、興味もないし知らないという尖った知識の持ち主である。尖ったオトコが綴るブログに期待したい。

初稿はInnoDBにおけるテーブルスペースのインポートのHackに関する内容だ。これまで、innodb_files_per_tableオプションを利用している際にできるInnoDBのテーブルスペースのインポートは、テーブルスペースIDがマッチしていないといけないなどの制約があって面倒だったが、その辺の不都合な箇所を改良して任意のテーブルスペースをインポートする機能を、彼がInnoDBからforkしたXtraDBに実装していますという内容だ。

これからもどんどんマニアックでディープな記事が投稿されることだろう。彼のブログ発進を喜びたい!!

さらにMySQLを高速化する7つの方法

MySQLを高速化する10の方法という記事がとても好評だったようである。記事を読んで頂いた皆さん、ありがとう。

この記事に対する便乗（？）でWeb屋のネタ帳: PostgreSQLを高速化する16のポイントという記事を書いて頂いたようだが、そちらの方もかなり人気だったようである。他人が作ったソフトウェアに改良を加えるというフリーソフトウェアやオープンソースソフトウェアの精神も基本は便乗であるので、便乗については大いに賛成したいというかむしろ取り上げてくれてありがとう！！と思うわけであるが、ここでさらに俺はこう考える。

さらに自分も便乗するしかない！！

と。

MyISAMからInnoDBへ切り替えるときの注意点

MySQLを使い始めて間もない人がよく陥る罠の中に、気づくと使ってるストレージエンジンがMyISAMだった！ということがある。デフォルトのストレージエンジンはMyISAMなので、MySQLに詳しくない人たちが比較的陥りやすい罠なのだ。そもそもストレージエンジンという概念自体がMySQL独自のものなので仕方のない話である。MyISAMは素晴らしいストレージエンジン（たとえばこのYahoo!の中の人による投稿で言われているように）であるが、長所もあれば短所もある。

InnoDBテーブルスペースの空き領域

以前の投稿でも書いたが、InnoDBのテーブルスペースは一度大きくなってしまうと縮小することができない。ならば実際にはどれだけのスペースが使われているのか？という疑問が沸いてくることだろう。それは、innodb_file_per_tableオプションを利用しているときとそうでないときで見方が違う。

InnoDBのファイルサイズ管理

最近、InnoDBのデータ領域（テーブルスペース）が成長してしまって元に戻すことが出来ない場合の対処についてよく質問されるので、今日はテーブルスペースが成長することへの対策について説明しよう。（ここのところMySQLネタが続いているが、Planet MySQL日本語版を意識しているわけではないのであしからず！！＜＜ホントかよ？！＞俺）

InnoDBのログとテーブルスペースの関係

InnoDBのデータ領域はログファイルとテーブルスペースという、切っても切れない2種類のファイルから構成されている。ログファイルは名前からするとただのログだから削除しても平気かな？と思って削除してしまうという問題が後を絶たない。そこで、今日はログファイルとテーブルスペースの関係について説明しようと思う。

InnoDBの達人

MySQLがなぜこれほどまでに普及したのかというのはその柔軟性や性能の高さ故であり、それらはストレージエンジンという仕組み無しには語れない。そして、MySQLのストレージエンジンといえばその代表格はInnoDBであろう。即ち、InnoDBを制するものは世界を制す！！と言っても過言ではないのである！！（世界は言い過ぎだけどな＞俺）

InnoDBについて、おそらくアジアで・・・もしかすると世界でも5本の指に入るであろうほど極めたオトコが日本に居る。それがMyNAでもお馴染みの木下氏である。