それでも好きです。。。

MySQL の設定が弄れない場合は ft_min_word_len や innodb_ft_min_token_size で単語最小単位の変更が出来ない。 または不用意に設定ファイルは弄りたくない場合に全文検索で単語の最小単位 (4 だったり 3 だったり) に対応したときのメモ。

全文検索時の揺らぎ (例えば 「カキクケコ」 が 「かきくけこ」 でも検索できる) は使わないので、テーブル作成時のオプションで CHARSET や COLLATE の指定はしない。 COLLATE を指定するにしても utf8mb4_bin など 末尾に _bin が付くものにする。

全文検索用のテーブルは個別で用意する

重要なデータが入ったテーブルに全文検索用のカラムは用意しない。

これは好みの問題かもしれない。

文字を一定規則に沿ってノーマライズする

全角英数字は半角へ。半角へ置換可能な全角記号も半角へ。大文字英字は小文字へ。カタカナはひらがなへ。面倒でなければ半角カタカナも全角へ (濁点の処理が面倒)。

これは揺らぎの検索が出来ないことの対策。

重複する文字はまとめる

例えば 「2011/11/11」 を bigram にすると 「20 01 11 1/ /1 11 1/ /1 11」 となり、重複を省くと 「20 01 11 1/ /1」 となります。

各単語は人間が読める意味のある文字の並びである必要は無いため、重複するのは削除して構わない。 11 月の 「11」 と 11 日の 「11」 は 2 つとも保存する意味があるか？ 無いですよね。

プログラムでは bigram の 2 文字をキーにした連想配列を使えば重複する 2 文字はまとめられる。

データベースへの保存は文字コードで行う

「20 01 11 1/ /1」 を文字コードにすると 「3230 3031 3131 312f 2f31」 となります。 (2 文字ペアの bigram でも文字コードにすれば 4 文字になることに注目)

文字コードにしておけば、検索時に % や * を使うと syntax error になるのも防げるし、エスケープする必要も無い。

以上。

ただでさえデータ量が多くなる ngram なのに、文字コードで保存するからデータ量がさらに倍になるのが欠点っちゃ欠点。