MySQL InnoDBストレージエンジンのチューニング(前編)

EnterpriseZine / 2012年3月9日 0時0分

本連載では、3回にわたってチューニングの要であるオプティマイザについて説明してきた。オプティマイザは論理的な表現であるクエリを物理的にどう処理するかということを決めるRDBMSの心臓部であると言える。しかしながら、人体が心臓だけで機能しないのと同じように、RDBMSもオプティマイザだけで成り立つわけではない。実際に手足となりデータを操作するのはストレージエンジンだ。今回は、MySQLの代表的な(実質的にはデファクトスタンダードの)ストレージエンジンであるInnoDBの基本的なチューニングについて解説しようと思う。クエリのチューニングとは全くストラテジーが異なるので、これまで連載を読んで頂いている方は、ここで頭を切り替えて欲しい。

■InnoDBを使おう!

 もし本稿を読まれている方で、特に明確な意味もなくまだMyISAMストレージエンジンを使ってらっしゃるという方には、全力でInnoDBをオススメしたい。InnoDBには、MyISAMにはない様々な利点があるからだ。
トランザクション対応

 InnoDBはACID準拠のトランザクションに対応している。トランザクションの利点は改めて語るまでもないが、DBAの負担を減らしてくれることは間違いない。トランザクションに対応していないストレージエンジンは、集計用の一時的な領域などには良いかも知れないが、文字通りトランザクションを処理するには無理がある。原子性がないということは、処理が失敗したらたちまちデータに不整合が生じるということだし、永続性がないということはOSやマシンのクラッシュ時にはデータが破損する可能性があるということだ。やってできなくはないが、わざわざリスクを抱えてデータベースを運用することはないだろう。(MyISAMと比べて、InnoDBを用いるとデッドロックなどでトランザクションが失敗したときのエラー処理を記述する必要が出てくる。MyISAMではエラー処理を記述しないで利用できるので一見すると楽に思えるが、実際には単に開発の負担を運用に押し付けているだけであるといえる。)

 InnoDBでは、トランザクションにおいて次のような機能を利用可能だ。
XAトランザクション セーブポイント 4つの分離レベル READ-UNCOMMITTED READ-COMMITTED REPEATABLE-READ SERIALIZABLE 高い並列性

  • 前のページ
    • 1
    • 2
  • 次のページ
EnterpriseZine

トピックスRSS

ランキング