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
MySQL::Sandbox (2) - 日向夏特殊応援部隊
MySQL::Sandbox - Yet Another Hackadelic の続きです。 make_replication_sandbox でレプリ環境をサクっと作る レプリ環境もサクっと作れます。前と同じバイナリがあるとしたら、 $ make_replication_sandbox /home/zigorou/tmp/mysql-5.0.82-linux-i686-glibc23.tar.gz executing "clear" on slave 1 executing "clear" on slave 2 executing "clear" on master installing and starting master installing slave 1 installing slave 2 starting slave 1 . sandbox server started s
SYSDATE()とNOW()の違い。
MySQLには、現在時刻を求める関数としてSYSDATE()とNOW()という2つの関数が実装されている。そして、それらは微妙に動作が違う。SYSDATE()は関数が呼び出された瞬間の時刻を返すのに対して、NOW()はクエリ開始時の時刻を返す。例えば、100秒かかるような長いクエリにおいて両者を利用した場合、SYSDATE()では結果に最大100秒の差が生じるのに対して、NOW()では差が生じない。NOW()では関数が最初に実行された時に結果がキャッシュされ、以降はキャッシュされた値が利用されるからだ。 次のようにSLEEP()を利用するとわかり易いだろう。 mysql> SELECT SYSDATE(), SLEEP(100), SYSDATE(); +---------------------+------------+---------------------+ | SYSDATE(
MySQLのEXPLAINを徹底解説!!
以前、MySQLを高速化する10の方法という投稿で「EXPLAINの見方についてはいずれ解説しようと思う」と書いてしまったので、今日はその公約？を果たそうと思う。 MySQLのチューニングで最も大切なのは、クエリとスキーマの最適化である。スキーマの設計は一度決めてしまうとそのテーブルを利用する全てのクエリに影響してしまうためなかなか変更することは出来ないが、クエリはそのクエリだけを書き直せば良いので変更の敷居は低い。そして遅いクエリをなくすことは、性能を大幅に向上させるための最も有効な手段である。従って、アプリケーションの性能を向上させたいなら、まず最初にクエリのチューニングを検討するべきなのである。 最適化するべきクエリはスロークエリログやクエリアナライザで見付けられるが、ではそのようなクエリが見つかった場合にはどのように最適化すればいいのか？そのためにはまず現在どのようにクエリが実行さ
なぜMySQLのサブクエリは遅いのか。
よくMySQLはサブクエリが弱いと言われるが、これは本当だろうか？半分は本当で半分は嘘である。MySQLのサブクエリだってなんでもかんでも遅いわけではない。落とし穴をしっかり避け、使いどころを間違えなければサブクエリも高速に実行できるのである。今日はMySQLがどんな風にサブクエリを実行し、どのような場合に遅いのかということについて説明しよう。 EXPLAINで実行計画を調べた際に、select_typeにはクエリの種類が表示されるのだが、代表的なサブクエリには次の3つのパターンがある。 SUBQUERY DEPENDENT SUBQUERY DERIVED 結論から言おう。遅いのは2番目、DEPENDENT SUBQUERYである。DEPENDENT SUBQUERYとはいわゆる相関サブクエリに相当するもので、サブクエリにおいて外部クエリのカラムを参照しているサブクエリのことである。そし
MySQL 5.1のスロークエリログ
MySQL 5.1で追加されたメジャーな機能の影に隠れた、地味だが便利な改善がある。それがスロークエリログに関する仕様である。MySQL 5.0まではスロークエリログは1秒未満のクエリを捕捉することが出来なかった。が、MySQL 5.1では1マイクロ秒までのクエリを記録できるようになっている。従って、0.5秒かかるけど大量に実行されてパフォーマンスに大きな影響を与えている！というようなクエリの発見が出来るようになった。1秒未満のクエリを追跡したい場合、例えば以下のような設定をする。 [mysqld] slow_query_log=ON slow_query_log_file=mysql-slow.log long_query_time=0.1 MySQL 5.0まではlog_slow_queryというオプションだったのが、MySQL 5.1ではslow_query_logというオプション名
InnoDBのファイルサイズ管理
最近、InnoDBのデータ領域（テーブルスペース）が成長してしまって元に戻すことが出来ない場合の対処についてよく質問されるので、今日はテーブルスペースが成長することへの対策について説明しよう。（ここのところMySQLネタが続いているが、Planet MySQL日本語版を意識しているわけではないのであしからず！！＜＜ホントかよ？！＞俺） InnoDBのテーブルスペースが成長してしまうのは、ズバリ自動拡張しているからである。テーブルスペースに対して何もオプションを指定しないと、デフォルトでは次のような設定と同じテーブルスペースが作成される。 [mysqld] innodb_data_file_path=ibdata1:10M:autoextend サイズは10MBしかないが、自動拡張するのである。自動拡張してしまうと何が問題なのかというと、データが増えた場合にファイルシステムの空き領域を使い切
漢(オトコ)のコンピュータ道: MySQLを高速化する10の方法
ちょっとキャッチ−なタイトルをつけてしまったが、今日は独断と偏見でMySQLを高速化する方法を10個紹介しよう。MySQLサーバをチューニングするときや初期導入する場合などに参考にしてもらいたい。 1. バッファを増やす、または減らす チューニングの基本中の基本であるが、適切なバッファサイズを設定することはパフォーマンスチューニングの要である。主なバッファは次の通り。 innodb_buffer_pool_size・・・InnoDBだけを利用する場合は空きメモリの7〜8割程度を割り当てる最も重要なバッファである。余談だが、実際にはここで割り当てた値の5〜10%ぐらいを多めにメモリを使うので注意が必要だ。 key_buffer_size・・・MyISAMだけを利用する場合は、空きメモリの3割程度を割り当てるといい。残りはファイルシステムのキャッシュ用に残しておこう。 sort_buffer_
[ThinkIT] 第3回：MemoryとArchive (1/3)
今回は、「Memory」と「Archive」の2つのストレージエンジンを取り上げます。Memoryエンジンは比較的古いMySQLのバージョンから提供されており、以前はHeapと呼ばれていたストレージエンジンです。もう一方のArchiveエンジンは、MySQL 4.1から提供されている比較的新しいエンジンです。 それでは、それぞれの特長やテーブルファイルの構成について解説します。 Memoryエンジンは、その名前の通りテーブルデータすべてをメモリ上にのみ格納します。これは、変更結果をディスク上に書き出さないことを意味します。変更データもメモリ上に存在しているため、アプリケーションからの問い合わせは、このメモリ上のデータに対して処理を行なって結果を返します。 ただし、MySQLサーバが終了するとテーブルデータが消滅してしまいますので、当然変更結果も消滅します。ここでいうMySQLサーバの終了と
MySQL の filesort プチテクニック - kazuhoのメモ置き場
MySQL のチューニング関連のドキュメントを読んでいると「ORDER BY を避けろ」と書いてあるけど、できない (or したくない) 場合もあるわけで。そういう時はソート用の表と表示用の表を分割し自己結合することで、高速化できることもあります。適当な例ですが、 mysql> SHOW CREATE TABLE testt\G *************************** 1. row *************************** Table: testt Create Table: CREATE TABLE `testt` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `priority` int(10) unsigned NOT NULL, `data` varchar(255) NOT NULL, PRIMAR
サブクエリやっぱりさっぱり意味がわからないな - @kyanny's blog
ERROR 1241 (ER_SUBSELECT_NO_1_ROW) SQLSTATE = 21000 Message = "Subquery returns more than 1 row" このエラーは次のような場合に発生する。 SELECT * FROM t1 WHERE column1 = (SELECT column1 FROM t2); ただし、これは t2 に複数のレコードが存在する場合に限られる。たとえば、このエラーは長い間使用されているコードで発生することがある。つまり、サブクエリで返すことができるレコード数に影響するような変更を誰かが行ったような場合である。1 つに限らず任意の数のレコードをオブジェクトで検出するようにするときの正しいステートメントは、次のようになる。 SELECT * FROM t1 WHERE column1 = ANY (SELECT column
Kazuho@Cybozu Labs: ウェブサービスにおけるダメージコントロール (MySQL のスロークエリを自動的に kill する方法)
« ウェブサービスにおける SSD 導入にむけて〜検索サービスの可能性 | メイン | ウェブアプリケーションのインストーラジェネレータ » 2008年11月04日 ウェブサービスにおけるダメージコントロール (MySQL のスロークエリを自動的に kill する方法) 適切な設計によって、信頼性の高いソフトウェアやサービスを構築することが重要なのは、言うまでもないことです。一方で、なんらかの原因で問題が発生した際に、障害を局所化し、損害を小さく食い止める「ダメージコントロール」という概念もあります。ウェブサービスの場合も、特に検索や集計といった、計算量がクエリの種類によって大幅に異なるようなケースでは、次善の策として後者の手法が有効に働く場合もあるかと思います。 ともかくそういうわけで、MySQL のスロークエリを強制終了するようなタスクを書きやすくする Perl モジュール MySQL
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MySQL Bugs: #41980: SBL, INSERT .. SELECT .. LIMIT = ERROR, even when @@SQL_LOG_BIN is 0 !
Kazuho@Cybozu Labs: MySQL の order by 〜 limit を高速化する方法
https://hibinokoto.jp/archives/2008/11/post-299.html