1

私はmysqlデータベースを使用しています。私のウェブサイトはさまざまな要素に分割されています（プロジェクト12の場合はPRJ_12、タスク14の場合はTSK_14、ドキュメント18の場合はDOC_18など）。現在、これらの要素への参照をVARCHARとしてデータベースに保存しています。リレーション列にはインデックスが付けられているため、選択が高速です。

これらの列を2つの列（PRJの「element_type」列と12の「element_id」列）でcurrintすることを考えています。LIKE ...％を含む多くのリクエストを実行するため、このソリューションを検討しています（たとえば、タスクのIDに関係なく、1人のユーザーのすべてのタスクを取得します）。ただし、これらの列を2つに分割すると、インデックス付き列の数が増えます。

だから、私は2つの質問があります：

  1. インデックス付き列のリクエストはLIKE ...%、単純なwhereクエリ（likeなし）よりも実際に低速です。列にインデックスが付けられていない場合、where ... LIKE %リクエストを行うことはお勧めできませんが、インデックスがどのように機能するかはよくわかりません）。
  2. 参照列を2つに分割すると、インデックス付きテーブルの数が2倍になります。問題ありますか？

ありがとう、

4

2 に答える 2

1

1) like は常に完全な比較 ( = を使用) よりもコストがかかりますが、すべてはフィールドのデータ型とレコードの数に帰着します (巨大なテーブルについて話している場合を除き、問題はないはずです)。

2）複数列のインデックスは問題ではありません。はい、インデックスが大きくなりますが、それでどうですか？データ型と総行数は重要ですが、それがインデックスの目的です。

だからそれのために行く

于 2013-02-07T16:32:05.020 に答える
0

関連する要因は多数ありますが、一般に、インデックスが 1 つしかないテーブルにインデックスをもう 1 つ追加しても、大きな問題になることはほとんどありません。考慮すべきいくつかのこと。

  • テーブルの大部分が読み取り専用である場合、ほぼ確実に問題にはなりません。更新がめったにない場合、インデックスを頻繁に変更する必要はありません。つまり、余分なコストはほとんどありません (追加のディスク領域は別として)。
  • 既存のレコードを更新してもこれらのキー値のいずれも変更されない場合、インデックスの変更は必要ないため、追加のランタイム コストは発生しません。
  • DELETES と INSERTS は、両方のインデックスを更新する必要があります。したがって、それが操作の大部分である場合 (読み取りをはるかに超える場合)、インデックスを追加すると、パフォーマンスが大幅に低下する可能性があります (ただし、それほど大きくなく、人間の観点からは目立たない可能性があります)。
  • 使用法を説明する like 演算子は、完全に最適化する必要があります。つまり、句は、両方の状況でインデックスが存在する場合WHERE combinedfield LIKE 'PRJ%'と本質的に同じように機能する必要があります。WHERE element_type = 'PRJ'先頭にワイルドカードを使用すると、コストが高くなります (例: LIKE '%abc%')。LIKE 検索は、辞書で単語を検索するのと同じと考えることができます。「overf%」の検索は、基本的に「overflow」の検索と同じです。辞書で「手動」バイナリ検索を実行すると、「overf」で始まる最初の単語をすばやく見つけることができます。「%low」を検索すると、はるかにコストがかかります。「low」で終わるすべての単語を見つけるには、辞書全体をスキャンする必要があります。
  • 2 つの個別の値を表す 2 つの個別のフィールドを持つことは、より効率的なクエリを作成したり、結合を簡単に実行したりできるため、長期的にはほとんど常に優れています。

したがって、与えられた情報に基づいて、それを 2 つのフィールドに分割し、両方のフィールドにインデックスを付けることをお勧めします。

于 2013-02-07T17:50:06.643 に答える