現行の制限事項について

MySQL Senna Tritonn

これまでいくつかのパタンについては内部的に回避する実装を追加してきているのですが、frmファイルにアクセスするような処理はいまでもいくつかUSING句情報が落ちるものがあります。

例えば以下のようにテーブルを定義しているものとします。

CREATE TABLE t1 (c1 TEXT, FULLTEXT INDEX ft USING NGRAM, 1024 (c1)) DEFAULT CHARSET utf8;

この時、以下のどれかの処理を行うと、USING以下で指定した情報（ここではindex_type=NGRAMとinitial_n_segments=1024）が落ちます。

  • TRUNCATE TABLE t1
  • CREATE TABLE t2 LIKE t1
  • REPAIR TABLE t1 USE_FRM

具体的には、SHOW SENNA STATUSで確認すると以下のようになってしまいます。

[test] > show senna status\G
*************************** 1. row ***************************
                  Table: t1
               Key_name: ft
            Column_name: c1
               Encoding: euc_jp
             Index_type: MECAB
              Normalize: OFF
            Split_alpha: OFF
            Split_digit: OFF
           Split_symbol: OFF
     Initial_n_segments: 512
        Senna_keys_size: 1
   Senna_keys_file_size: 8462336
     Senna_lexicon_size: 15
Senna_lexicon_file_size: 12656640
     Senna_inv_seg_size: 430080
   Senna_inv_chunk_size: 135168
1 row in set (0.00 sec)

index_typeがMECABに、normalizeがOFFに、initial_n_segmentsが512となってしまいます。

現在、Tritonn(MySQL+Sennaパッチ)ではUSING句以下の情報をfrmファイルには保存せず、アクセス時に適宜、SEN系ファイルからsen_index_info関数を通じて取得するという実装方法を採っているのですが、そのためMySQLが内部でfrmファイルから取得した情報を使ってインデックスの作成を行うような場合に、このようなことになっています。

これまでは、例えばALTER TABLEなどのいくつかのパタンについては、MySQLがfrmファイルから情報を取得した直後のタイミングで内部的にsen_index_infoを追加呼出しして情報を補完するような実装を追加して少しずつ対処してきていました。

これを今後、frmファイルを使う方法に行くか、駄目パタンを少しずつ潰していく現行の方法を維持するかについてはまだ議論の余地があると思っているのですが、とりあえず上記については今日時点では対応できていません。

回避方法としては、上記のようなクエリを別のクエリで代替できるならそっちを使うか、あるいは上記クエリを使用するならその後にALTER/DROP/CREATEでUSING句情報を明示してインデックスを再作成して下さい。

尚、Tritonnの制限事項については以下のページにまとめていますので、気になった時にチェックしてみてください。
http://qwik.jp/tritonn/limitation.html