我有類似下面的SQL查詢：查詢優化（ORDER BY）
SELECT NAME,
MY_FUNCTION(NAME) -- carries out some string manipulation
FROM TITLES
ORDER BY NAME; -- has an index.
titles表具有約12,000條記錄。目前查詢需要5分鐘才能執行，但如果我刪除了ORDER BY子句，那麼它會在幾秒鐘內執行。
有沒有人有關於如何加快此查詢的任何建議。
使用EXPLAIN語句，看看那裏的問題是
EXPLAIN SELECT NAME, MY_FUNCTION(NAME) FROM TITLES ORDER BY NAME;
如果創建my_function是確定的（即始終返回相同的輸入值相同的結果），那麼你可以創建（名稱，創建my_function（名））的指數，它可以幫助（或可能不會！）
我不明白爲什麼（NAME，MY_FUNCTION（NAME））上的索引能夠幫助他/她的查詢。 :( – 2010-11-10 12:46:09
因爲查詢可以通過單獨閱讀索引來解決，而不是表格 - 索引已經按照NAME順序。 – 2010-11-10 12:50:32
好點。沒想到那個。 – 2010-11-10 13:15:52
聽起來怪怪的。什麼是name列類型？
您是否檢查過有缺陷的硬件錯誤？也許（也許）你的查詢與order by子句使用你的索引，並且你的索引位於有缺陷的磁盤中（如果它們位於不同的表空間中，它可能位於不同的磁盤中）。
不是很奇怪的是，ORDER BY可能導致所有數據在被返回前執行SORT – 2010-11-10 12:51:46
同意但是'ORDER BY'可以在'name'上使用索引，他/她聲稱必須避免排序，另外，排序12000條記錄應該不會超過幾秒鐘，顯然需要5分鐘！ – 2010-11-10 12:56:15
確實，5分鐘是12000行很長的時間 – 2010-11-10 13:14:23
在這個問題下評論，你說，它需要2秒。「來而不順序返回N行BY」。這是有道理的：如果沒有ORDER BY，只要碰到它們，你就會得到遇到的前N行。使用ORDER BY，在之後，只有返回前N行，結果已按正確順序排序。
如果查詢在快速獲得第N行的情況下使用是很重要的（如在線報告與分頁），那麼你可以嘗試添加FIRST_ROWS或FIRST_ROWS_ ñ提示查詢，嘗試說服它使用索引。請參閱Choosing an Optimizer Goal
您說「相似」。真正的查詢在哪些方面不同 - 它是否連接多個表（或者它是基於一個視圖嗎？）它實際上是否也從表中選擇了許多其他列？ – 2010-11-10 13:15:55
另外，當你說如果沒有ORDER BY它會在幾秒鐘內執行，是返回所有數據還是僅返回第N行來顯示？ – 2010-11-10 13:16:46
@PeteDaMeat，你有比較兩個查詢的查詢計劃嗎？ – 2010-11-10 13:22:41