Ceekz Logs (Move to y.ceek.jp): 2007年07月23日アーカイブ

2007年07月23日

MySQL では、1テーブルにつき1インデックスしか使用できないという制約がある（作成は出来る）。そのため、高速な問い合わせを可能にするには WHERE, ORDER で出現する全てのカラムの組み合わせで、マルチカラムインデックスを作成する必要がある。

その問題を回避するためだけにでも Tritonn （Senna）を導入する価値がありそう。ベータ段階ではあるが、「2ind機能」が複数のインデックスを利用可能にする。最新の MySQL 5 にも同等機能が実装されているが、微妙に使いにくい（WHERE, ORDER でまたげないのが致命的）。

MySQLが全文検索用のインデックスと通常のインデックスの両方を併用できるようにする2ind機能が利用できます。

「全文検索用のインデックス」となっているが、その他のインデックスとの組み合わせでも作動を確認した。ソートの際に、マルチカラムインデックスを準備する必要が無い（もちろん完全な作動を保障していない）。

・試したクエリ

SELECT
  *
FROM
  book
    FORCE INDEX(review)
WHERE
  price < 800
ORDER BY
  review;

price, review は、別々にインデックスを作成している（マルチカラムインデックスではない）。更なる検証は後日行うつもり（まさに必要としているので検証せざるを得ない）。まずは、他の検証例を探してみますか。

自分で Senna のインストールをしたことが無いので、自己環境の整備が急務。

※追記

低速になるクエリ文を見つけた。保障していない作動だろうか。

・低速になる例

SELECT
  *
FROM
  book
    FORCE INDEX(review)
WHERE
  price = 800
ORDER BY
  review;

MySQL のインデックスで完全一致を行った後、パッチの機能を用いてソートするとインデックスを利用しない場合（FORCE INDEX 未使用時）よりも低速になる。件数にもよるのだろうか。インデックスの利用は key_buffer_size あたりの値も影響するので、切り分けが面倒…。

【関連情報】
・Tritonn機能紹介 - Tritonnプロジェクト
　http://qwik.jp/tritonn/feature.html
・6.2.6. インデックス結合最適化 - MySQL
　http://dev.mysql.com/doc/refman/5.1/ja/index-merge-optimization.html
・MySQL5からのインデックス結合で１テーブル複数インデックスを使う - ウノウラボ
　http://labs.unoh.net/2007/06/mysql5.html

やはり首が痛い。ということで、昨日（22日）の食事内容です。

昼は、モスに行きました。キャンペーンスタンプを押してくれなかった（#^ω^）ﾋﾞｷﾋﾞｷ

ウーロン唐揚げ

夜は、夢屋に行ったら終わってた。様々な場所を巡回した後、北方園に落ち着いた。なにやら半貸切状態で、うるさかったのですが、中国料理の大衆食堂系は、どこでもうるさいですね…。にぎやかと言うのか。

首が痛いのは、ディスプレイを覗き込むように見るからかな…。見上げるようにした方がマシかもしれない。作業場所を自宅から、某所に変えるかな。某所の机は、キーボードだけ低く出来るので見上げての作業をしやすそう。

モスバーガー（昼）
　テリヤキチキン, オニポテ, コーラ
北方園（夜）
　ウーロン唐揚げ