binlog の設定等によって大きく変わると思うので要注意ですが、テストによっては、これぐらい差が出ます。

測定環境は MySQL 5.1.35; linux 2.6.18; x86_64。

テーブルのスキーマは、

CREATE TABLE `hoge` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `text` varchar(255) NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=500001 DEFAULT CHARSET=utf8;

mysqlslap のパラメータは、

mysqlslap -c 20 -i 5000 -q 'insert into test.hoge (text) values ("aaa")'

別に、MySQL のストレージエンジンじゃなくて UDF でもいいんですが*1。

理由は、トリガーのオーディティングとかロギングとかデバッグとかで、ログをはきたいから。MyISAM みたいな non-transactional なストレージエンジンにログを INSERT していってもいいんだけど *2、tail -f できないとか面倒だし。

　最近 RDBMS のトリガーを色々書いているのですが、知らない人にトリガーが何かいちいち説明するのに簡単な例はないかな、というのと、MySQL の処理速度はトリガーによってどの程度変化するか、ということを確認するために、以下のような実験を行ってみました。

　InnoDB はしばしば、「SELECT COUNT(*) が遅い！」と批判されます。では、トリガーを使って行数を別のテーブルにキャッシュすればいいのではないでしょうか？　以下のように、極めて小さなテーブル t1 を作り、その行数を t1_cnt にキャッシュしてみることにします。

mysql> create table t1 (
    ->   id int unsigned not null primary key

　Q4M (Queue for MySQL) の mutex と rwlock のうち主要な部分を、「スレッド間で共有する変数のアクセス権制御を C++ コンパイラで強制する方法」で紹介させていただいたロック手法 (以下 CAC) を使うようリファクタリングしました。変更の過程でバグらしきものは見つかりませんでした^注が、なにか未発見のバグが直っていたりする可能性、あるいは品質維持を考えて、今後は CAC ベースのリリースにしていこうと思っています。

　というわけで、非 CAC ベースの最終版 (0.8.6)、および CAC リリース (0.8.7) の最新版のプレリリース (バイナリ版は

しばらくブログを更新していなかったのですがそろそろ再開しようと思います。

ここ半年くらいTritonnに動きがなかったと思うのですが、この間新しいストレージエンジンの開発に着手していました。Sennaの後継プロダクトとしてgroongaがリリースされましたが、このgroongaをMySQLのストレージエンジンにするというものです。

新しいストレージエンジンはもうしばらくしたらテストリリースする予定です。

従来のMySQL 5.0向けのTritonn(MyISAM+Senna)は大きなトラブル(落ちるバグなど)も無かったのでしばらくアップデートしていませんでしたが、こちらも来月あたりにアップデート版をリリースしようと思っています。

このアップデート版ではMySQL