0

作業中のテーブルにパフォーマンスの問題があり、この問題に対する適切な解決策が見つからないようです。due インデックスを作成しましたが、何百万もの行があり、クエリはまだ非常に遅いです。

テーブルは、トークンごとに他の情報を含むトークンに分割されたテキストを表します。全文検索エンジンを使用してこれを行うことができたと考える人もいるかもしれませんが、そうではありません. お願い、私を信じて。

テーブル スキーマは次のとおりです。

CREATE TABLE `midia_lemmatized_text`
(
    `IdFile` CHAR(15) NOT NULL,
    `Position` INTEGER NOT NULL,
    `WordForm` VARCHAR(48) NOT NULL,
    `Pos` VARCHAR(16) NOT NULL,
    `Lemma` VARCHAR(64) NOT NULL,
    PRIMARY KEY (`IdFile`,`Position`),
    INDEX `midia_lemmatized_text_FI_2` (`Pos`),
    INDEX `midia_lemmatized_text_FI_3` (`WordForm`),
    CONSTRAINT `midia_lemmatized_text_FK_1`
        FOREIGN KEY (`IdFile`)
        REFERENCES `midia_metadata` (`Id`),
    CONSTRAINT `midia_lemmatized_text_FK_2`
        FOREIGN KEY (`Pos`)
        REFERENCES `midia_pos` (`Pos`)
) ENGINE=InnoDB CHARACTER SET='utf8';

どこ

  • IdFile外部キーです
  • Positionファイル内の現在のトークンの位置を指定するインデックス位置です
  • WordFormトークンそのものです
  • PoSは単語形式の品詞です
  • Lemma語形の補題

行の例:

1, 1, 'The', 'ART', 'The'
1, 2, 'table', 'NOUN', 'table'
1, 3, 'is', 'VER', 'be'
...

クエリ

問題のあるクエリは次のようなものです。

前後の10 個の単語に囲まれた、文脈で "rivolgimento" であるすべての語形を検索します

: 10 は別の数字である可能性があり、コンテクスト ワードはカンマ、ドットなどでもあります。

結果の例は次のとおりです。

cuor trasparente , mi par bene di conchiuder con affettuoso rivolgimento alla dissimulazione stessa . O virtù che sei il

私が今行っていることは、一致した各行のすべてのIdFileと番号を取得し、それらをループして前後の N 単語を取得することです。Positionお分かりのように、これは 1 + N 個のクエリを意味し、N が大きいと応答が非常に遅くなります。

主な問題は、列で REGEX を使用して検索することもできるため、クエリがさらに遅くなることです。

GROUP_CONCATを使用することを考えましたが、正確な方法がわかりません。

4

2 に答える 2