MySQLクエリとMATCHとAGAINSTがハングアップ

Question

多くの社内サイトのデータを共有データベースに収集する複数のCURLスクリプトがあります。各スクリプトは「インスタンス」と呼ばれます。データはレコード形式でデータベースに追加されます。各レコードには複数の「フィールド」があり、これはキーと値のペアです。各レコードのキーは動的であり、何か（たとえ同じインスタンスであっても）である可能性があるため、MySQLテーブルにハードコードされていません。

は、したがって、これらのテーブルがあります

1. 記録 - 各インスタンス
2. record_fieldsに関連付けられ、レコードのリストが含まれている - は、レコード
3. に関連付けられたフィールドのリストが含まれていますrecord_fields_labels - 基本的にラベルのリスト。これはスペースを節約するためにデータベースに保存されています（つまり、record_fieldsには「Article Date」というラベルを持つ何千ものフィールドがあります）、すべてrecord_labels上のレコードのIDである番号8を持ちます。 "をその価値とする）。

record_fieldsとrecord_fields_labelsはFULLTEXT「コンテンツ」（実際のデータを含むrecord_fieldsの列）のインデックスと「ラベル」（ラベル名を持つrecord_fields_labelsの列）の両方MyISAMテーブルです。

データベースは数百万レコードを持っている - 各レコードのフィールドの数を掛けるために... インスタンスは、レコードがデータベースにすでに存在するかどうかを確認するために、実行すると、彼らは次のSQLクエリを実行します。

SELECT r.id FROM records r INNER JOIN record_fields rf ON rf.record_id=r.id INNER JOIN record_fields_labels as rfl ON rf.label=rfl.id WHERE r.instance IN (120) AND MATCH (rf.content) AGAINST ('"http://xxxx.xxxx/xxx.xxx.xxx"' IN BOOLEAN MODE) AND MATCH (rfl.label) AGAINST ('"Article URL"' IN BOOLEAN MODE) GROUP BY r.id 

この例では、http://xxxx.xxxx/xxx.xxx.xxxは、スクリプトがシステムにすでに存在するかどうかをチェックする記事のURLです。

TL; DR

問題は、このです：データベースが巨大である場合（すなわち、記録/レコードフィールドの数百万） - 上記のクエリは、単に電話を切りました。明白な理由がなくても、何時間もクエリが実行されます。この同じクエリは、収集されたデータ内の項目を検索するために使用され、動作するように見える（または最近まで働いた）。

私が欲しいのは、そのようなレコードが存在するかどうかを示すことです。 インデックス作成の問題ではないようですが、特にMATCH AGAINSTとは何かが関係しています。私はスペースを節約するために、（FULL TEXTインデックスに加えて）すべてのコンテンツのインデックスを追加することを避けることを好みます。

誰かがこのハングアップの問題の原因を知っていますか？

おかげ

Answer 1

あなたは、特にあなたのラベルのために、あなたがする必要はありませんFULL TEXTインデックスを使用しているように見えます。これらがシンプルでよく定義されていれば、通常のインデックスはうまくいくでしょう。 「記事の日付」と「ブログの日付」を区別する必要がある場合は、たとえば、コンテンツタイプに1つ、データタイプに1つのフィールドを使用します。あなたはMATCH AGAINSTを使用して語句を検索する場合

... BOOLEAN MODEでは、実際に同じ順序ではなく、完全な文字列に同じ言葉を探しています...DOCS

が実際にマッチします、あなたのフィールドの内容に「http://xxxx.yyy/www.zzz.mmm」の検索を参照してください「ここにhttp一部のコンテンツをXXXX。YYYのWWW！MMM ZZZ？はい、より多くのコンテンツください」とそれはあなたの全文最小ワード長を想定していますが3ですか、もっと少なく。パフォーマンスとロジックに関しては、これは正しいインデックスではありません。

あなたは完全なテキストインデックスをURLとラベルに入れないようにデータ構造を変更することを真剣に検討します。これにより、通常のインデックスの使用を避けるよりも多くのスペースを節約できます。