慢MySQL查詢/ IN子句

我有〜100000個條目的數據庫 - 現在我的查詢看起來是這樣的：慢MySQL查詢/ IN子句

SELECT ID，郵編，價格從上市WHERE郵編IN（96815，96815， 96835 ，96828,96830,96826,96836,96844,96816,96847,96814,96822, 96823,96843,96805,96806,96810,96848,96808,96809,96842,96839, 96802,96812,96804,96803,96840，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 6701,96860,96709,96782,96706,96797,96862,96789, 96707,96730,96854,96759,96786,96857,96717,96792,96762,96712, 96791,96731）和（價格在1000和1200之間的價格） ORDER BY ID

這個查詢工作得很好，當我只有50 000個，但它變得非常緩慢，當我延長了郵政編碼的半徑（這將導致更多的郵政編碼的條款）。

ID INT（8）AUTO_INCREMENT價格MEDIUMINT（7）郵政編碼MEDIUMINT（5）

所有三個字段索引。有沒有人有一個想法，我可以優化它？謝謝你們

來源

2011-07-14 Manuel

我敢肯定，如果你有一個索引，很多郵政編碼在IN子句中即使該字段被索引，它也會運行緩慢。我不知道如何解決這個問題，除了限制拉鍊的數量。 –

我可以在郵政編碼列表中看到重複的值。確保你只給出不同的值和增量。 – ysrb

郵政編碼一般地理上分佈的 - 你也許能夠通過簡化郵政編碼子句類似加快速度：

zipcode BETWEEN 96700 AND 96898

這可能最終會在不經意間包括一些郵政編碼，你不想要，但最終可能會更有效地過濾掉它們。

來源

2011-07-14 23:49:26 duskwuff

聽起來似乎合理 - 看起來有點幫助 – Manuel

被索引的每個字段和被正確索引的字段之間存在很大差異。至於我能看到你只需要一個索引，使查詢運行得更快

嘗試創建一個具有以下列（郵編，價格）

來源

2011-07-15 02:13:49

問題是我還有其他疑問（所以我需要其他兩列的索引）。主要關心的是zip查詢。 – Manuel

這很好，如果其他查詢使用索引，但我的意思是，僅僅因爲您在列上有索引，並不意味着您的查詢可以使用它。創建包含兩列的索引，並讓我知道它是否有幫助。 –

慢MySQL查詢/ IN子句

回答

相關問題