我們在做一些查詢的時候總希望能避免資料庫引擎做全表掃描,因為全表掃描時間長,而且其中大部分掃描對用戶端而言是沒有意義的。那麼在
MySQL
中有那些方式是可以避免全表掃面的呢?除了我們大家很熟悉的通過使用索引列或分區等方式來進行查詢的最佳化之外還有那些呢?
前些天看了一個老外寫的程式,在
MySQL
查詢中使用了很多
Limit
關鍵字,這就讓我高度興趣了,因為在我印象中,
Limit
關鍵字似乎更多被使用
MySQL
資料庫的程式員用來做查詢分頁(當然這也是一種很好的查詢最佳化),那在這裡舉個例子,假設我們需要一個分頁的查詢
,Oracle中一般來說都是用以下
SQL
句子實現:
SELECT * FROM
( SELECT a1.*, rownum rownum_
FROM testtable a1
WHERE rownum > 20)
WHERE rownum_ <= 1000
這個語句就能查詢到
testtable
表中的
20
到
1000
記錄,而且還需要巢狀查詢,效率不會太高,看看
MySQL
的實現:
SELECT * FROM testtable a1 limit 20,980;
這樣就能返回
testtable
表中的
21
條到(
20
+
980
=)
1000
條的記錄。
實現文法確實簡單,但如果要說這裡兩個
SQL
語句的效率,那就很難做比較了,因為在
MySQL
中
Limit
選項有多種不同的解釋方式,不同方式下的速度差異是很大的,因此我們不能從這語句的簡潔程度就說誰的效率高。
不過對程式員來說,夠簡單就好,因為維護成本低,呵呵。
下面講講這個
Limit
的文法吧:
SELECT ……. --Select
語句的其他參數
[LIMIT {[offset,] row_count | row_count OFFSET offset}]
這裡
offset
是位移量(這個位移量的起始地址是
0
,而不是
1
,這點很容易搞錯的)顧名思義就是離開起始點的位置,而
row-count
也是很簡單的,就是返回的記錄的數量限制。
Eg. SELECT * FROM testtable a limit 10,20 where ….
這樣就能使結果返回
10
行以後(包括
10
行自身)的符合
where
條件的
20
條記錄。
那麼如果沒有約束條件就返回
10
到
29
行的記錄。
那這跟避免全表掃描有什麼關係呢?
下面是
MySQL
手冊對
Limit
參數最佳化掃描的一些說明:
在一些情況中,當你使用
LIMIT
選項而不是使用
HAVING
時,
MySQL
將以不同方式處理查詢。
l
如果你用
LIMIT
只選擇其中一部分行,當
MySQL
一般會做完整的表掃描時,但在某些情況下會使用索引(跟
ipart
有關)。
l
如果你將
LIMIT n
與
ORDER BY
同時使用,在
MySQL
找到了第一個合格記錄後,將結束排序而不是排序整個表。
l
當
LIMIT n
和
DISTINCT
同時使用時,
MySQL
在找到一個記錄後將停止查詢。
l
某些情況下,
GROUP BY
能通過順序讀取鍵
(
或在鍵上做排序
)
來解決,並然後計算摘要直到索引值改變。在這種情況下,
LIMIT n
將不計算任何不必要的
GROUP
。
l
當
MySQL
完成發送第
n
行到用戶端,它將放棄餘下的查詢。
l
而
LIMIT 0
選項總是快速返回一個空記錄。這對檢查查詢並且得到結果列的列類型是有用的。
l
暫存資料表的大小使用
LIMIT #
計算需要多少空間來解決查詢。
轉自:
http://www.blogjava.net/chenpengyi/archive/2006/07/29/60679.html