現在、Stack Overflowのコメントのデータダンプに対していくつかのクエリを実行しようとしています。スキーマは次のようになります。

CREATE TABLE `socomments` (
  `Id` int(11) NOT NULL,
  `PostId` int(11) NOT NULL,
  `Score` int(11) DEFAULT NULL,
  `Text` varchar(600) NOT NULL,
  `CreationDate` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  `UserId` int(11) NOT NULL,
  PRIMARY KEY (`Id`),
  KEY `idx_socomments_PostId` (`PostId`),
  KEY `CreationDate` (`CreationDate`),
  FULLTEXT KEY `Text` (`Text`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8

このクエリをテーブルに対して実行し、信じられないほど低速で実行しました（2900万行ありますが、フルテキストインデックスがあります）。

SELECT *
FROM socomments
WHERE MATCH (Text) AGAINST ('"fixed the post"' IN BOOLEAN MODE)

そこで、私はそれをプロファイルしました。その結果は次のとおりです。

|| Status                     || Duration ||
|| starting                   || 0.000058 ||
|| checking permissions       || 0.000006 ||
|| Opening tables             || 0.000014 ||
|| init                       || 0.000019 ||
|| System lock                || 0.000006 ||
|| optimizing                 || 0.000007 ||
|| statistics                 || 0.000013 ||
|| preparing                  || 0.000005 ||
|| FULLTEXT initialization    || 207.1112 ||
|| executing                  || 0.000009 ||
|| Sending data               || 0.000856 ||
|| end                        || 0.000004 ||
|| query end                  || 0.000004 ||
|| closing tables             || 0.000006 ||
|| freeing items              || 0.000059 ||
|| logging slow query         || 0.000037 ||
|| cleaning up                || 0.000046 ||

ご覧のとおり、FULLTEXTの初期化には長い時間がかかります。これは正常ですか？そうでない場合、どのように修正しますか？

他の人はこれを厄介な状況だと感じました

• MySQL 5.6でのInnoDB全文検索：パート3、パフォーマンス
• InnoDB Fulltext Search WITH QUERY EXPANSIONは非常に遅い
  • 2010年9月16日
  • 5.0.51a、5.0.75、5.0 bzr
  • ステータス：フィードバックなし
• SELECTクエリがFULLTEXT初期化状態でハングする
  • 2014年10月17日
  • MySQL 5.6.19
  • ステータス：修正しない

以来MySQLのドキュメントは、このスレッドの状態に非常に簡潔です

全文初期化

サーバーは、自然言語の全文検索を実行する準備をしています。

唯一の手段は、より少ないデータで準備を行うことです。どうやって ？

提案＃1

クエリをもう一度見てください。すべての列を選択しています。クエリをリファクタリングして、からid列のみを収集しますsocomments。次に、取得したIDをsocommentsテーブルに結合します。

SELECT B.* FROM
(SELECT id FROM socomments
WHERE MATCH (Text) AGAINST ('"fixed the post"' IN BOOLEAN MODE)) A
LEFT JOIN socomments B USING (id);

これによりいEXPLAINプランが作成される可能性がありますが、プロファイリングはより良くなると思います。基本的な考え方は次のとおりです。積極的なFULLTEXT検索を使用している場合は、そのFULLTEXT initialization段階で収集するデータの量を最小限にして、時間を短縮します。

私はこれを何度もお勧めしました

• May 14, 2012：フルテキストおよび左結合を使用したクエリの低速化
• Mar 18, 2012：MySQLのFULLTEXTインデックスでLIKEがMATCH ... AGAINSTより4倍以上速いのはなぜですか？
• Jan 26, 2012：Mysql全文検索my.cnf最適化：
• Oct 25, 2011：ブールモードで「単語数」条件付きのFULLTEXTインデックスは無視されます

提案＃2

MyISAMのオプションではなく、InnoDBベースのFULLTEXTオプションを設定していることを確認してください。心配する必要がある2つのオプションは

• innodb_ft_cache_size
  • デフォルト値8000000（7.629M）
  • 最大値80000000（76.29M）
• innodb_ft_total_cache_size
  • デフォルト値640000000（610M）
  • 最大値1600000000（1525M = 1.49G）

少し考えてみてください。テキストフィールドはVARCHAR（600）です。平均が300バイトだとします。あなたはそれらの29,000,000万を持っています。それは8GBの少しになるでしょう。おそらくinnodb_ft_cache_sizeとinnodb_ft_total_cache_sizeを増やすことも役立つかもしれません。

より大きなInnoDB FULLTEXTバッファーに十分なRAMがあることを確認してください。

試してみる ！！！

InnoDB FULLTEXTインデックスを使用している場合、削除された行が多数あるテーブルに対してクエリを実行すると、クエリは「FULLTEXT初期化」状態でハングすることがよくあります。InnoDBのFULLTEXT実装では、影響を受けるテーブルに対して後続のOPTIMIZE操作が実行されるまで、削除された行は整理されません。参照：https : //dev.mysql.com/doc/refman/5.6/en/innodb-fulltext-index.html

削除されたレコードのフルテキストインデックスエントリを削除するには、innodb_optimize_fulltext_only = ONを指定してインデックス付きテーブルでOPTIMIZE TABLEを実行し、フルテキストインデックスを再構築する必要があります。

information_schema.innodb_ft_deletedをクエリすることにより、削除されたがパージされていないレコードの数を調べることもできます。

これを解決するには、InnoDB FULLTEXTインデックスを持つテーブルに対してOPTIMIZE TABLEを定期的に実行する必要があります。

MySQLには確認済みのバグがあり（InnoDB FULLTEXTテーブルの最適化中に削除されたDOCIDは維持されません）、大量の削除負荷の下でパフォーマンスを低下させます（テーブルを最初から再構築せずに）。

関連。

MySQLのフルテキストインデックスは大量のデータをサポートするようには設計されていないため、データセットが大きくなるにつれて検索速度が非常に速く低下します。ソリューションの1つは、SolrやSphinxなどの外部フルテキスト検索エンジンを使用することです。これにより、検索機能（関連性の調整とフレーズ検索のサポート、組み込みファセット、スニペットなど）が拡張され、クエリ構文が中程度になり、速度が大幅に向上します-大規模なデータセット。

SolrはJavaプラットフォームに基づいているため、Javaベースのアプリケーションを実行するのが自然な選択になる場合、SphinxはC ++で記述され、MySQLと同じ方法でデーモンとして機能します。検索したいデータを外部エンジンに供給するとすぐに、いくつかのクエリをMySQLから移動することもできます。どのエンジンがあなたの場合に優れているかはわかりませんが、私は主にSphinxを使用しています。使用例は次のとおりです。http：//astellar.com/2011/12/replacing-mysql-full-text-search-with-sphinx/