4

この構造のテーブルがあり、現在約160万件のレコードが含まれています。

CREATE TABLE `chatindex` (
    `timestamp` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
    `roomname` varchar(90) COLLATE utf8_bin NOT NULL,
    `username` varchar(60) COLLATE utf8_bin NOT NULL,
    `filecount` int(10) unsigned NOT NULL,
    `connection` int(2) unsigned NOT NULL,
    `primaryip` int(10) unsigned NOT NULL,
    `primaryport` int(2) unsigned NOT NULL,
    `rank` int(1) NOT NULL,
    `hashcode` varchar(12) COLLATE utf8_bin NOT NULL,
    PRIMARY KEY (`timestamp`,`roomname`,`username`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;

roomname列とusername列の両方に同じ正確なデータを含めることができますが、各項目の一意性と重要なビットは、タイムスタンプとこれら2つの項目の組み合わせに由来します。

しばらく（10〜20秒）かかり始めているクエリは次のとおりです。

SELECT timestamp,roomname,username,primaryip,primaryport 
    FROM `chatindex`
    WHERE username LIKE '%partialusername%'

これを最適化するために正確に何ができますか？partialusername%一部のクエリでは、実際のユーザー名の中央のほんの少ししかなく、実際の値の先頭から最初の数文字がないため、実行できません。

編集：

また、この特定の目的にはスフィンクスの方が適していますか？

4

6 に答える 6

5

フルテキスト インデックスを使用します。これらは実際にはこの目的のために設計されています。InnoDb は、MySQL 5.6.4 でフルテキスト インデックスをサポートするようになりました。

于 2012-07-06T06:39:03.003 に答える
4
  1. テーブル列のユーザー名にインデックスを作成します (フルテキスト インデックス作成)。
  2. アイデアとして、アルファベットやその他の基準に基づいてフィルタリングされたデータを含むこのテーブルにいくつかのビューを作成し、それに基づいてコードが検索結果のフェッチに使用するビューを決定することができます。
于 2012-07-06T06:54:44.200 に答える
2

MyISAM テーブルは FULLTEXT インデックスをサポートしているため、検索には MyISAM テーブルを使用する必要がFulltextあります。MySQL v5.6+ はまだ開発段階にあるため、運用サーバーとして使用しないでください。GA になるまでに 1 年ほどかかる場合があります。

ここで、このテーブルを MyISAM として変換columnし、where 句で参照する FULLTEXT インデックスを追加する必要があります。

次のリンクが役立ちます。

http://dev.mysql.com/doc/refman/5.0/en/create-index.html

http://dev.mysql.com/doc/refman/5.1/en/fulltext-fine-tuning.html

于 2012-07-06T07:32:01.840 に答える
1

MSSQL では、CONTAIN 句と一緒にフルテキスト インデックスを使用するのに最適なケースです。LIKE 句は、このような大きなテーブルで、検索するテキストのバリアントが非常に多いため、良好なパフォーマンスを得ることができません。

このリンクを見てください。動的検索条件に関連する多くの問題があります。

于 2012-07-06T06:43:09.193 に答える
1

現在のクエリで Explain を実行すると、テーブルの完全なテーブル スキャンを実行していることがわかります。これが非常に遅い理由です。ユーザー名のインデックスは、MySQL によってインデックスがキャッシュされる可能性があり、一致するユーザーに対してのみテーブル行のエントリにアクセスできるため、検索が大幅に高速化されます。

フルテキスト インデックスは、一致などの検索に実質的に役立つわけではないため、他の人がこれを使用することを推奨している理由がわかりません。フルテキスト インデックスが行うことは、単語リスト ベースのインデックスを作成して、「explain the current query」のようなものを検索するリストを作成することです。フルテキスト エンジンは、「explain」を含む行 ID と、「current」を含む行 ID および「query」を含む行 ID を交差させます。 " 3 つすべてを含む ID のリストを取得します。フルテキスト インデックスを追加すると、テーブルの挿入、更新、削除のコストが大幅に増加するため、パフォーマンスが低下します。さらに、フルテキスト インデックスを最大限に活用するには、フルテキスト固有の "MATCH" 構文を使用する必要があります。%fred%oldfredboy

「[mysql] fulltext like」で質問を検索すると、これに関する詳細な説明が表示されます。

通常のインデックスは、必要なすべてを行います。'%fred%' のような検索では、何をするにしてもインデックスのフル スキャンが必要になるため、インデックスをできるだけ無駄のない状態に保つ必要があります。また、「fred%」に一致するヒットの割合が高い場合は、最初に「fred%」のような検索を試す価値があるかもしれません。これはインデックス範囲スキャンを行うからです。

もう 1 点、タイムスタンプ、部屋名、ユーザー名を主キーとして使用している理由を教えてください。これは私には意味がありません。主キーをアクセス パスとして使用しない場合は、auto_increment id の方が簡単です。部屋名、タイムスタンプ、ユーザー名は、時間枠内で部屋にアクセスする傾向があるため、ある程度意味があると思いました。

使用するインデックスのみを追加してください。

于 2012-07-06T10:02:37.090 に答える
0

このような大量のデータには、テーブルインデックス（フルテキストインデックス）が必要です。さらに、可能であれば、テーブルのパーティション化に進みます。したがって、これらは間違いなくパフォーマンスを向上させます。

于 2012-07-19T02:38:38.657 に答える