スローMySQLのクエリは、/句

では、私は〜100,000件のエントリを使用してデータベースを持っている - 今、私のクエリは次のようになります。スローMySQLのクエリは、/句

SELECT ID、郵便番号、価格郵便番号（96815、96815、 96835、INリストFROM 、96828、96830、96826、96836、96844、96816、96847、96814、96822、、96823、96843、96805、96806、96810、96848、96808、96809、96842、96839、 96802、96812、96804、96803、96840 96807、96813、96841、96801、96850、、96811、96898、96837、96827、96824、96846、96821、96817、96859、96838、、96819、96820、96858、96849、96825、96795、96863、96818、96853 、96861、、96734、96744、9 96709、96730、96854、96759、96786、96857、96717、96792、96762、96712、、96791、96731）AND（価格は1000 AND 1200） ORDER BY id

このクエリは、50,000のエントリしかなかったときにうまくいきましたが、郵便番号の半径を広げると、実際には遅くなりました（これはin節にさらに郵便番号が入ります）。

のID INT（8）AUTO_INCREMENT価格MEDIUMINT（7）ジップコードMEDIUMINT（5）

すべての3つのフィールドがインデックス付けされます。誰も私はそれを最適化する方法のアイデアを持っていますか？みんなありがとう

出典

2011-07-14 Manuel

私はあなたが多くの郵便番号を持っている場合ことをかなり確信していますフィールドが索引付けされていても、IN節では遅く実行されます。私はzipの数を制限するだけでなく、これをどのように修正するかわかりません。 –

郵便番号のリストに重複した値が表示されます。個別の値と増分だけを指定してください。 – ysrb

ZIPコードは、一般的に、地理的に分散している - あなたのような何かにZIPコード句を簡素化することによって物事をスピードアップすることができるかもしれません：これはうっかりそのあなた、いくつかの郵便番号を含む終わる可能性があり

zipcode BETWEEN 96700 AND 96898

後でフィルタリングする方が効率的になる可能性があります。

出典

2011-07-14 23:49:26 duskwuff

他の2つの列のインデックスが必要なので、他のクエリも同様に問題になることがあります。 – Manuel

インデックスが作成される各フィールドとフィールドが正しくインデックス付けされることには大きな違いがあります。私の知る限り、あなただけ

は、次の列（郵便番号、価格）を使用して索引を作成してみ速くクエリの実行を行うために一つの指標を必要と見ることができるように

出典

2011-07-15 02:13:49

ビットが役に立ちます。主な関心事は、ジップクエリです。 – Manuel

インデックスが他のクエリで使用されている場合は問題ありませんが、その意味は、インデックスに列があるからといって、クエリで使用できるわけではありません。両方の列を含む索引を作成し、それが役立つかどうか教えてください。 –

スローMySQLのクエリは、/句

答えて

関連する問題