當使用where子句時，緩慢的mysql查詢

我已經拍攝了一個郵政編碼數據庫，並且預先計算了在某個半徑範圍內與其他郵政編碼的距離。數據庫本身大約是2.5GB，所以沒有什麼特別的。當使用where子句時，緩慢的mysql查詢

這樣做的目的是能夠：

select * from zipcode_distances where zipcode_from=92101 and distance < 10;

迄今爲止唯一的指標，我定義是：

(zipcode_from, distance)

但是，運行查詢需要約20秒得到結果。

當我刪除「and distance < 10」子句時，結果是即時的。

任何意見，將不勝感激。

編輯：

這裏是create語句：

delimiter $$ 

CREATE TABLE `zipcode_distances` (
    `id` int(10) unsigned NOT NULL AUTO_INCREMENT, 
    `zipcode_from` char(5) COLLATE utf8_bin NOT NULL, 
    `zipcode_to` char(5) COLLATE utf8_bin NOT NULL, 
    `distance` double unsigned NOT NULL COMMENT 'stored in miles', 
    PRIMARY KEY (`id`), 
    KEY `idx_zip_from_distance` (`zipcode_from`,`distance`) 
) ENGINE=MyISAM AUTO_INCREMENT=62548721 DEFAULT CHARSET=utf8 COLLATE=utf8_bin$$

這裏的解釋：

explain extended select * from zipcode_distances where zipcode_from=90210 and distance < 10;

結果：

ID，SELECT_TYPE，表，possible_keys ，key，key_len，ref，rows，過濾，超1，操作簡便，zipcode_distances，ALL， idx_zip_from_distance，NULL，NULL，NULL，62548720，100.00，使用其中

謝謝！

來源

2012-12-30 john

請粘貼解釋計劃和表格構造 –

請顯示錶格佈局，因爲目前很難提供幫助，除非我們看到您的數據存儲距離到郵政編碼的距離。 – donlaur

嘗試'SELECT some_column FROM ...'開始。 – markus

我發現沒有問題MySQL使用查詢索引。我想知道92101的類型轉換是否會令人困惑。

你是否因此得到同樣糟糕的表現？

select * from zipcode_distances where zipcode_from='92101' and distance < 10;

另一個問題是你如何做的時間。您必須多次運行才能避免填充緩存的影響。

來源

2012-12-30 18:31:08

這是正確的;類型轉換是罪魁禍首！謝謝！！ – john

只是一個提示：請你做一個解釋擴展，粘貼以及警告。通常在警告中，您將獲得將被執行的aproximate查詢以及您的案例的轉換函數。這些類型的錯誤最初很難追蹤，因爲一切似乎都很正常。應該提出問題的一件事是它是一個完整的表掃描（可能存在的更糟糕的掃描類型之一）。接下來，您需要啓用警告並解決轉換問題。 – Xnoise

當使用where子句時，緩慢的mysql查詢

回答

相關問題