一、基本
sql的limit語法的如以下形式
select * from table
limit
[offset
,] rows
|rows
offset
offset
當省略offset
的時候，
offset作為0
處理，表示提取查詢到的前
rows
條資料；
當offse
t>
=0時候，表示提取查詢到的
從offset
開始的rows
條資料；此時如果
rows
<0
表示提取查詢到的
從offset
開始的所有資料
當offset
<0
的時候，表示提取查詢到的除出後
rows
條資料的所有資料，即剔除
last row
-rows
到last rows
之間的-
rows
條資料
另外，如果
rows
大於實際查詢的資料條數，則取
rows
為實際查詢的資料條數。
二、例項
例項1
檢索記錄行 6-15
select * from table limit 5,10;
為了檢索從某乙個偏移量到記錄集的結束所有的記錄行，可以指定
rows
引數為 -1：
例項2
檢索記錄行 96-last
select * from table limit 95,-1;
如果只給定
rows
引數，它表示前
rows
條資料；換句話說，limit n 等價於 limit 0,n
例項3
檢索前 5 個記錄行
select * from table limit 5;
例項4
返回第6-15行資料
select * from table limit 5,10;
或select * from table limit 5;
或select * from table limit 0,5;
例項5
返回0到
last row
-rows的資料
select * from class limit
10, -1
或 select * from class limit
-1 offset 10
假如現在class表中有100條資料，則返回的是0開始的90條資料，即0到（100-
10）三、效能
3.1、基本
1、offset比較小的時候。
select * from yanxue8_visit limit 10,10
多次執行，時間保持在0.0004-0.0005之間
select
*from yanxue8_visit where vid >=(
select
vidfrom yanxue8_visit order by vid limit 10,1
) limit 10
多次執行，時間保持在0.0005-0.0006之間，主要是0.0006
結論：
偏移offset較小的時候，直接使用limit較優。這個顯然是子查詢的原因。
2、offset大的時候。
select * from yanxue8_visit limit 10000,10
多次執行，時間保持在0.0187左右
select
* from yanxue8_visit where vid >=(
select
vidfrom yanxue8_visit order by vid limit 10000,1
) limit 10
多次執行，時間保持在0.0061左右，只有前者的1/3。可以預計offset越大，後者越優。
3.2、效能優化：
方案1.
select * from cyclopedia where id>=(
select max(id) from (
select id from cyclopedia order by id limit 90001
) as tmp
) limit 100;
方案2.
select * from cyclopedia where id>=(
select max(id) from (
select
idfrom cyclopedia order by id limit 90000,1
) as tmp
) limit 100;
同樣是取90000條後100條記錄,第1句快還是第2句快?
第1方案是先取了前90001條記錄,取其中最大乙個id值作為起始標識,然後利用它可以快速定位下100條記錄
第2方案擇是僅僅取90000條記錄後1條,然後取id值作起始標識定位下100條記錄
第1方案執行結果.100 rows in set (0.23) sec
第2方案執行結果.100 rows in set (0.19) sec
很明顯第2方案勝出.
因為這裡id是
主鍵，所以不會去做全表掃瞄，而是直接返回
limit offset+length條記錄,這樣看來limit比起ms-sql的top效能還是要提高不少的.
其實第2個方案完全可以簡化成
select * from cyclopedia where id>=(
select
idfrom cyclopedia limit 90000,1
)limit 100;
直接利用第90000條記錄的id,不用經過max運算,這樣做理論上效率因該高一些,但在實際使用中幾乎看不到效果,因為本身定位id返回的就是1條記錄,max幾乎不用運作就能得到結果,但這樣寫更清淅明朗,省去了畫蛇那一足.
可是,既然mysql有limit可以直接控制取出記錄的位置,為什麼不乾脆用select * from cyclopedia limit 90000,1呢?豈不更簡潔?
這 樣想就錯了,試了就知道,結果是:1 row in set (8.88) sec,怎麼樣,夠嚇人的吧。select * 最好不要隨便用,要本著用什麼,選什麼的原則, select的字段越多,字段資料量越大,速度就越慢. 另外，第2方案中，
id是主鍵，所以不會去做全表掃瞄，而是直接返回
limit offset+length條記錄。
第1種方案同樣可用於ms-sql,而且可能是最好的.因為靠主鍵id來定位起始段總是最快的.
select top 100 * from cyclopedia where id>=(
select top 90001 max(id) from (
select id from cyclopedia order by id
) as tmp
)但不管是實現方式是存貯過程還是直接**中,瓶頸始終在於ms-sql的top總是要返回前n個記錄,這種情況在資料量不大時感受不深,但如果成百上千萬,效率肯定會低下的.相比之下mysql的limit就有優勢的多,執行:
select id from cyclopedia limit 90000
select id from cyclopedia limit 90000,1
的結果分別是:
90000 rows in set (0.36) sec
1 row in set (0.06) sec
而ms-sql只能用select top 90000 id from cyclopedia 執行時間是390ms,執行同樣的操作時間也不及mysql的360ms.
update與limit 關鍵字使用
更新前30行的某個字段內容，沒什麼問題。更新從20行到30行的某個欄位的內容，這樣會報錯。這樣就能實現更新表中根據id公升序排序的第20條到第30條資料的某個欄位的內容 注意 如果這樣的話也是不行的 update tb name set column name test where id in se...
MySQL中any some all關鍵字
mysql中any some all關鍵字 any關鍵字 假設any內部的查詢語句返回的結果個數是三個，那麼，select from where a any select from where a result1 or a result2 or a result3 all關鍵字 all關鍵字與any...
MySQL 中 explain關鍵字
select 查詢的序列號，包含一組數字，表示查詢中執行 select 子句或操作表的順序。三種情況 id 相同 執行順序由上而下 from t1,t2,t3 where t1.id t2.id and t1.id t3.id and t1.other column from t2 where id...