木下氏はInnoDBのスペシャリストであり、おそらく実力はアジア一だろう。しかもレプリケーションなど、MySQLの他の機能に関しては、興味もないし知らないという尖った知識の持ち主である。尖ったオトコが綴るブログに期待したい。 初稿はInnoDBにおけるテーブルスペースのインポートのHackに関する内容だ。これまで、innodb_files_per_tableオプションを利用している際にできるInnoDBのテーブルスペースのインポートは、テーブルスペースIDがマッチしていないといけないなどの制約があって面倒だったが、その辺の不都合な箇所を改良して任意のテーブルスペースをインポートする機能を、彼がInnoDBからforkしたXtraDBに実装していますという内容だ。 これからもどんどんマニアックでディープな記事が投稿されることだろう。彼のブログ発進を喜びたい!!

ピンポイントチューニング講座です。まずは結果から。 このグラフは、以下のテーブルに50,000レコードINSERTしたときの処理時間を示したものです。性能に70倍以上もの差が出ているのはなぜか、見ていきたいと思います。 CREATE TABLE `loadtest` ( `id` int(11) NOT NULL, `data` varchar(100) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 方法1 ベースライン conn = DriverManager.getConnection(JDBC_URL, JDBC_USER, JDBC_PASS); pstmt = conn.prepareStatement("insert into loadtest (id, data) values (?

MySQL 6.0.11-alphaがリリースされた。が、アナウンスレターには気になる記述がひとこと。「これはMySQL 6.0の最後のリリースです」と。寝耳に水かも知れないがこの話は本当だ。実はこれが最後のMySQL 6.0のリリースになる。つまり、MySQL 6.0の開発はこれでストップするのだ。 などと心配しないで頂きたい。MySQLの開発はちゃんと継続される。開発の方針が変更されることになったからMySQL 6.0のリリースが見送られただけである。（ちなみに、次期バージョンはMySQL 5.4で、MySQL 6.0はその次のバージョンになる予定だったものである。といっても、MySQL 5.4は後から間に挿入された形なのだが。）理由は、ここのところMySQLの新バージョンのリリーススケジュールが遅れがちだったり色々と問題があったからだ。（何かが変更されるときは大抵その背景には問題があ

どこまで出来るか?!やれるところまでやってやるぜ!!と、威勢が良いのは若い間だけの話。オトナのオトコは、攻めるときはとことん攻めるが自らの限界もわきまえて賢く振る舞うのがスマートってものである。というわけで、今日はMySQLのいろいろな限界についてまとめてみる。皆さんも是非MySQLの限界を知り、MySQLをもっとスマートに使って頂きたい。 SQL文の最大長 MySQLサーバーが実行出来るSQL文の最大長は、max_allowed_packetシステム変数で表される。max_allowed_packetの最大値は1GBである。max_allowed_packetの値はセッションごとにも設定可能なので、デフォルトではそこそこの値（16MBなど）に設定しておいて、必要に応じて大きな対を使うと良いだろう。 データベースの個数 データベースオブジェクトの個数に制限はない。データベースオブジェクトは

オープンソースソフトウェアは一体誰のものなのか、というテーマを考える上で、現在のMySQLは格好の材料だ。 2008年2月、Sun MicrosystemsがMySQL Abを買収 2009年1月、MySQLの創設者Monty Wideniusが、MySQLのコミュニティブランチであるMariaDBをリリース 2009年2月、Monty WideniusはSunを退社し、MySQL関連のエンジニアリングサービスとMariaDBの開発をするMonty Program Abを設立 2009年4月、OracleがSunを買収 2009年5月、Monty Wideniusが、MySQL、派生コード、バイナリ、トレーニング、サポートなどを提供する中立的なコンソシアムOpen Data Allianceを設立 MySQLをとりまく環境は上記のようにめまぐるしく変わっている。プロプラエタリ・ソフトウェア

MySQLにはFOSS License Exceptionという制度がある。そのような制度があることはあまり知られていないし、名前を知っていても内容はよく知らない、または誤解しているという人が結構居る。そこで、FOSS License Exceptionについて改めてここで紹介したい。 MySQL FOSS License Exception http://www.mysql.com/about/legal/licensing/foss-exception/ 知っての通り、MySQLはデュアルライセンスだ。無料で公開されているMySQL Community ServerはGPLv2でライセンスされており、その他に有料のコマーシャル・ライセンス版が存在する。コマーシャル・ライセンス版はソースコードを公開したくないユーザー向けのライセンスで、俗にOEM版とも呼ばれる。 さて、FOSS Lice

テーブル定義を変更したい。インデックスが壊れてしまったので再作成したい。そんな場合はALTER TABLEを使う。ALTER TABLEはテーブル定義を変更するお馴染みのコマンドであるが、その挙動は意外と知られていない。（エキスパートとおぼしき方々からも度々質問を受ける。）そんなわけで、今日はALTER TABLEについて解説しようと思う。 まず結論から言うと、なんとMySQLのALTER TABLEはテーブルのデータを全てコピーし直すのである。なんて無駄なことを！？と思うかも知れないが、テーブル定義（スキーマ）の変更を動的に行うには、ストレージエンジンによるサポートが必要であり、動的なスキーマ変更をサポートしているストレージエンジンはまだ少ないのである。（動的スキーマ変更をサポートしているのはMySQL Clusterぐらいだ。しかも追加だけ。）デフォルトで利用出来るMyISAMはInn

MySQL 5.1から利用出来るパーティショニングの種類には、次の4つがある。 RANGEパーティショニング LISTパーティショニング [LINEAR] HASHパーティショニング [LINEAR] KEYパーティショニング RANGEパーティショニングは値の範囲を指定する。次のように日付を用いて範囲を指定するのが代表的な使い方だ。詳細はこちらの記事（パーティショニングの使用例 - http session情報）を見て欲しい。 mysql> CREATE TABLE http_session ( -> session_id VARCHAR(32) NOT NULL, -> last_access TIMESTAMP NOT NULL, -> created TIMESTAMP NOT NULL, -> t_session_data VARCHAR(1024) -> ...(中略)...

Adam Kennedyがきれいにまとめてくれていますが、先日来活発にコミットしてきたDBD::SQLiteが1.25の時点で正式にamalgamationを使うようになりましたので、これまでDBD::SQLite::Amalgamationを使っていた方はこの機会にぜひDBD::SQLiteの方に切り替えてくださいませ。 http://use.perl.org/~Alias/journal/38859 http://search.cpan.org/dist/DBD-SQLite/ 現状で過去数年間に報告されてきた大きな問題はあらかた解決されていますが、RT上に寄せられているストレステストなどの結果から、実際には微妙なリークや不正確なロックの問題が残っていることがわかっています。また、DBIの次の版が出たらいまfuncで呼び出しているもろもろの関数の呼び出し方を変える(install_me

MySQLのHAソリューションを調べてみました。(MySQL 5.1) MySQL Cluster MySQLコミュニティから提供されているクラスタソリューション メリット アクセス増などに対応するためのスケールアウトが比較的容易複数のノードのデータにアクセスするため、同時アクセスユーザが多い時の性能が向上する。(特に参照性能) (メモリにテーブルを作成するモード(以降メモリモード)の場合)冗長構成により耐障害性が向上する。 (メモリモードの場合はデメリットもあり)SQL実行エンジンとデータ蓄積部分を別のサーバにすることができるので、ボトルネックに応じて必要な部分に対してサーバの追加が可能。デメリット 複雑なクエリの実行は遅くなる傾向がある。複数のノードに同期して書き込むため、更新性能が落ちる場合がある。メモリモードの場合、データを蓄積するサーバが同時にすべてダウンしてしまうと、そのデータ

MySQLには、現在時刻を求める関数としてSYSDATE()とNOW()という2つの関数が実装されている。そして、それらは微妙に動作が違う。SYSDATE()は関数が呼び出された瞬間の時刻を返すのに対して、NOW()はクエリ開始時の時刻を返す。例えば、100秒かかるような長いクエリにおいて両者を利用した場合、SYSDATE()では結果に最大100秒の差が生じるのに対して、NOW()では差が生じない。NOW()では関数が最初に実行された時に結果がキャッシュされ、以降はキャッシュされた値が利用されるからだ。 次のようにSLEEP()を利用するとわかり易いだろう。 mysql> SELECT SYSDATE(), SLEEP(100), SYSDATE(); +---------------------+------------+---------------------+ | SYSDATE(

Oracleによる買収の報道とちょうど時期が重なってしまったのだが、実は今MySQL Conference & Expoの真っ最中なのである。買収のニュースのインパクトが大きすぎて霞んでしまいそうになるが、MySQL Conference & Expoにおいてなんと新しいバージョンのMySQLが発表された。MySQL 5.4である。次期バージョンは6.0とされていただけに驚いた人も多いだろうが、5.4は5.1から性能を改善し、6.0の機能をちょっとだけ先取りしたバージョンなのである。（そのバージョン番号の通り、5.1と6.0の中間的なバージョンというわけである。） MySQL 5.4の新規機能は次の通り。 InnoDBのスケーラビリティ改善（Googleの貢献！） SHOW ENGINE INNODB STATUSの拡張。（さらなる情報の表示） DTrace用Probeの追加（Solari

今日もパーティショニングの話の続きである。 パーティショニングが非常にフィットする（たぶん昨日の例よりも）もう一つのケースは、数日間だけ必要なデータを蓄えておくような場合だ。例えば、HTTPセッションやログ情報などが良い例ではないだろうか。そういう場合には、日付を使ってRANGEパーティショニングをするのである。RANGEパーティショニングでももちろんPruningによって性能の向上は出来るのだが、それよりも何よりも高速に不要なパーティションを破棄できるというのが大きい。パーティションの破棄は、内部的にはテーブルのDROPとほぼ同じ扱いなのである。DROPのスピードはストレージエンジンによるが、InnoDBやMyISAM、NDB（MySQL Cluster）ならばいくらデータを含んでいても関係なくDROPは一瞬である。テーブルから大量の行を削除すると、フラグメンテーションが発生したり、イン

MySQL 5.1.34がリリースされました。今回は25個の不具合が修正されています。 本日はmysqlクライアント側のバグをご紹介します。Bug#43254です。 mysql> set sql_select_limit = 0; Query OK, 0 rows affected (0.00 sec) mysql> use mysql セグメンテーション違反ですあとサーバがクラッシュするバグが1つありますが(Bug#43748)、これはおそらく誰も踏まないかな…。他に新機能の行ベースレプリケーションで修正が2つ出ているので(Bug#39701、Bug#42977)、行ベースレプリケーションを使っている方はチェックしておきましょう。

MySQL 5.1で追加された機能にパーティショニングがある。これは適切に利用すれば非常に強力な機能であることは間違いないのだが、使いどころが難しい。なぜなら、 インデックスをつけるだけでカバー出来る場合が多い。 パーショニングを使わずに、単にテーブルを分けてしまえばいい。 テーブルが巨大にならないとあまり効果を実感できない。 使い方を間違えると性能が落ちてしまう。 などの問題があるからだろう。 そんなわけで、今日と明日でパーティショニングが役に立つシーンを2つ紹介しようと思う。今日は一つ目、インデックスをつけたいカラムのカーディナリティが低い場合だ。カーディナリティとは日本語に訳すと濃度とか訳されるが、要は値の種類（分散具合）のことである。例えば、YesかNoの2つの値しかとらないカラムは非常にカーディナリティが低く、インデックスをつけるととても効率が悪い。インデックスを使って目的の行を

MySQL 5.1のmysqldumpslowを使うとチューニングが楽になる！という話題です。 mysqldumpslowはもともとMySQLに付属しているツールで、スロークエリログを集計してくれるものです。これ自体はMySQL 5.1で特に変わったところはありませんが、スロークエリログ本体の方が機能強化されているため、組み合わせるとなかなか便利になっています。MySQL 5.1におけるスロークエリログの主な機能強化は以下の三点です。 long_query_timeに1秒未満の値を設定できるようになった。 出力先を設定できるようになった。 これらの設定をオンラインで変更できるようになった。 これでどうなるかというと、MySQLの性能分析をしたいと思ったときに、サーバを止めずにその場で mysql> set global slow_query_log = 1; mysql> set glob

商品マスターのように参照専門で利用するテーブルならば、圧縮MyISAMが非常に適していることが多い。その方が容量が小さくなるし、ディスクI/Oが減るので高速化が期待出来るからだ。圧縮MyISAMを利用する時の問題点は、MySQLサーバ起動中にテーブルの圧縮を行えない点であろう。（正確には行えなくもないが、操作は慎重を期する必要がある。）また、圧縮MyISAMテーブルはひとたび圧縮してしまった後は、更新を加えることが出来ないのだが、如何に商品マスターといえども、一日に一度程度の頻度で更新をかけないといけないかも知れないので、これまた問題である。圧縮MyISAMテーブルを用いた運用は利点がある一方で、このような問題があるため難しい。そこで、今日は圧縮MyISAMテーブルで商品マスターを運用する方法について紹介しよう。 商品マスター作成用のMySQLサーバを用意する。オンライントランザクションを

長らくバグが放置されたままだったDBD::SQLiteですが、先日AliasことAdam Kennedyがメンテナを引き継いだのを受けて、いま何人かのCPAN Authorsが集まってごりごり直しています。tokuhiromさんのところでパッチが紹介されていたもののように、有名どころのバグはあらかた潰し終わって、これからSQLiteのソースをamalgamationに変えたり、unicodeまわりのバグを直したり、という作業が行われる予定なのですが、とりあえず一区切りということで、正式版の1.20が出ています。 Class::DBI、Jifty::DBI、Rose::DB、Data::ObjectDriverなどをお使いの方は、ぜひアップデートしてみてください（以上のものは、私のところで全部テストが通ることを確認済みです。ほかにテストしておいてほしいものがあったらご一報をば）。 追記：DO