0

この mysql クエリは、大きな (約 200,000 レコード、41 列) myisam テーブルで実行されます。

t1 から t1.* を選択します。tableここで、1 と t1. inactive= '0' および (t1. codelike '%searchtext%' または t1. namelike '%searchtext%' または t1. extlike '%searchtext%' ) t1 で並べ替えます。iddesc LIMIT 0、15

id はプライマリ インデックスです。

3 つの検索済み (類似) 列すべてに複数列インデックスを追加してみました。正常に動作しますが、結果は Web サイトの自動入力された ajax テーブルで提供され、2 秒の戻り遅延は少し遅すぎます。

また、3 つの列すべてに個別のインデックスを追加し、3 つの列すべてにフルテキスト インデックスを追加しようとしましたが、大幅な改善はありませんでした。

このタイプのクエリを最適化する最良の方法は何ですか? 1 秒未満のパフォーマンスを実現したいのですが、可能ですか?

4

2 に答える 2

0

あなたができる最善のことは、ページングを実装することです。何をしても、その IO コストは膨大になります。レコードの 1 ページのみを返す場合は、10/25/ またはそれが非常に役立ちます。

インデックスについては、計画を確認して、実際にインデックスが使用されているかどうかを確認する必要があります。フルテキスト インデックスが役立つ場合がありますが、それは返す行数と渡す内容によって異なります。% などのパラメーターを使用すると、実際にパフォーマンスが低下します。% で終わるが % で始まらない場合でも、インデックスを使用できます。検索するテキストの両側に % を付けると、インデックスはあまり役に立ちません。

于 2013-09-26T02:02:34.290 に答える
0

code、、nameおよびの 3 つの列をカバーするフルテキスト インデックスを作成できますext。MATCH() AGAINST ()次に、次の関数を使用して全文クエリを実行します。

select t1.*
from table t1
where match(code, name, ext) against ('searchtext')
order by t1.id desc
limit 0, 15

句を省略したORDER BY場合、行はデフォルトでMATCH関数結果の関連性値を使用してソートされます。詳細については、全文検索機能のドキュメントを参照してください。

@Vulcronosが指摘しているようにLIKE、ワイルドカードで始まる式で演算子が使用されている場合、クエリオプティマイザーはインデックスを使用できません%。

于 2013-09-26T02:18:49.403 に答える