最近 RDBMS のトリガーを色々書いているのですが、知らない人にトリガーが何かいちいち説明するのに簡単な例はないかな、というのと、MySQL の処理速度はトリガーによってどの程度変化するか、ということを確認するために、以下のような実験を行ってみました。 InnoDB はしばしば、「SELECT COUNT(*) が遅い!」と批判されます。では、トリガーを使って行数を別のテーブルにキャッシュすればいいのではないでしょうか? 以下のように、極めて小さなテーブル t1 を作り、その行数を t1_cnt にキャ... > このページを見る
Kazuho@Cybozu Labs: MySQL のトリガーの実用性を確認するために InnoDB の SELECT COUNT(*) を高速化してみる
developer.cybozu.co.jp
最終更新時間:
2009年06月29日17時23分
みんなのブックマーク 人気(0) 新着
- Triggerについて
- 「トリガーという機能特有のオーバーヘッドは、少なくともこの場合はない」が、多数の行を更新するような場合は当然注意が必要。
- 「トリガーという機能特有のオーバーヘッドは、少なくともこの場合はない」が、多数の行を更新するような場合は当然注意が必要。
- ↓id:sh2 あざっす。一応 Opteron 2218 x2 での測定ですが、落ち込みが小さいのは binlog がオフなのと innodb_flush_log_at_trx_commit=0 に設定してるからでしょうか
- trigger を使ってinsert をフックにカウントアップした値を使う。カウントキャッシュ列を更新するオーバーヘッドが生じる。select やupdate では実行されないが、トリガーは行ベース (1行毎に処理を行うタイプ) なので、多数の
- トリガーを使って行数を別のテーブルにキャッシュして高速化。 トリガーを使う事で1度のINSERTで2回INSERTが走るので書込パフォーマンスは約半分になるがSELECT COUNT(*)が高速に動作することが必須なら検討の余地あり
- http://dev.mysql.com/doc/refman/5.1/ja/triggers.html
- trigger
- trigger, トリガ
- trigger
- UPDATEによって処理がシリアライズされるので、デュアルコアなら2倍、クアッドコアなら4倍遅くなるのかも / id:kazuhooku 元のINSERTが4コアまでスケールしてないかも。前やったときは2.5コアぐらいまで伸びる程度でした
- trigger








