Kazuho@Cybozu Labs: MySQL のトリガーの実用性を確認するために InnoDB の SELECT COUNT(*) を高速化してみる

最近 RDBMS のトリガーを色々書いているのですが、知らない人にトリガーが何かいちいち説明するのに簡単な例はないかな、というのと、MySQL の処理速度はトリガーによってどの程度変化するか、ということを確認するために、以下のような実験を行ってみました。 InnoDB はしばしば、「SELECT COUNT(*) が遅い！」と批判されます。では、トリガーを使って行数を別のテーブルにキャッシュすればいいのではないでしょうか？ 以下のように、極めて小さなテーブル t1 を作り、その行数を t1_cnt にキャッシュしてみることにします。 mysql> create table t1 ( -> id int unsigned not null primary key auto_increment, -> v int unsigned not null -> ) engine=innodb

[Chisei]

Triggerについて

[dealforest]

「トリガーという機能特有のオーバーヘッドは、少なくともこの場合はない」が、多数の行を更新するような場合は当然注意が必要。

[hiro_y]

「トリガーという機能特有のオーバーヘッドは、少なくともこの場合はない」が、多数の行を更新するような場合は当然注意が必要。

[kazuhooku]

↓id:sh2 あざっす。一応 Opteron 2218 x2 での測定ですが、落ち込みが小さいのは binlog がオフなのと innodb_flush_log_at_trx_commit=0 に設定してるからでしょうか

[pitworks]

トリガーを使って行数を別のテーブルにキャッシュして高速化。 トリガーを使う事で1度のINSERTで2回INSERTが走るので書込パフォーマンスは約半分になるがSELECT COUNT(*)が高速に動作することが必須なら検討の余地あり

[hoisjp]

http://dev.mysql.com/doc/refman/5.1/ja/triggers.html

[mxg]

trigger

[aki77]

trigger, トリガ

[akkun_choi]

trigger

[sh2]

UPDATEによって処理がシリアライズされるので、デュアルコアなら2倍、クアッドコアなら4倍遅くなるのかも / id:kazuhooku 元のINSERTが4コアまでスケールしてないかも。前やったときは2.5コアぐらいまで伸びる程度でした

[hirose31]

trigger