問題：數據庫查詢語句，如何只返回一部分數據？
Top子句
TOP 子句用於規定要返回的記錄的數目。對於擁有數千條記錄的大型表來說，TOP 子句是非常有用的。
在SQL Server數據庫中語法為：
SELECT TOP number|percent column_name(s) FROM table_name
但是並非所有的數據庫系統都支持 TOP 子句，比如Oracle和MySQL，它們有等價的語法。
在Oracle數據庫中語法為：
SELECT column_name(s) FROM table_name WHERE ROWNUM <= number
在MySQL數據庫中語法為：
SELECT column_name(s) FROM table_name LIMIT number
MySQL的Limit子句
Limit子句可以被用於強制 SELECT 語句返回指定的記錄數。Limit接受一個或兩個數字參數。參數必須是一個整數常量。如果給定兩個參數，第一個參數指定第一個返回記錄行的偏移量，第二個參數指定返回記錄行的最大數目。
//初始記錄行的偏移量是 0(而不是 1)：
mysql> SELECT * FROM table LIMIT 5,10; //檢索記錄行6-15
//為了檢索從某一個偏移量到記錄集的結束所有的記錄行，可以指定第二個參數為 -1：
mysql> SELECT * FROM table LIMIT 95,-1; // 檢索記錄行 96-last
//如果只給定一個參數，它表示返回最大的記錄行數目。換句話說，LIMIT n 等價於 LIMIT 0,n：
mysql> SELECT * FROM table LIMIT 5; //檢索前 5 個記錄行
Limit的效率高？
常說的Limit的執行效率高，是對於一種特定條件下來說的：即數據庫的數量很大，但是只需要查詢一部分數據的情況。
高效率的原理是：避免全表掃描，提高查詢效率。
比如：每個用戶的email是唯一的，如果用戶使用email作為用戶名登陸的話，就需要查詢出email對應的一條記錄。
SELECT * FROM t_user WHERE email=?;
上面的語句實現了查詢email對應的一條用戶信息，但是由於email這一列沒有加索引，會導致全表掃描，效率會很低。
SELECT * FROM t_user WHERE email=? LIMIT 1;
加上LIMIT 1，只要找到了對應的一條記錄，就不會繼續向下掃描了，效率會大大提高。
Limit的效率低？
在一種情況下，使用limit效率低，那就是：只使用limit來查詢語句，並且偏移量特別大的情況
做以下實驗：
語句1：
select * from table limit 150000,1000;
語句2:
select * from table while id>=150000 limit 1000;
語句1為0.2077秒；語句2為0.0063秒
兩條語句的時間比是：語句1/語句2＝32.968
比較以上的數據時，我們可以發現采用where...limit....性能基本穩定，受偏移量和行數的影響不大，而單純采用limit的話，受偏移量的影響很大，當偏移量大到一定值后性能開始大幅下降。不過在數據量不大的情況下，兩者的區別不大。
所以應當先使用where等查詢語句，配合limit使用，效率才高
ps：在sql語句中，limit關鍵字是最后才用到的。以下條件的出現順序一般是：where->group by->having-order by->limit
附錄：OFFSET
為了與 PostgreSQL 兼容，MySQL 也支持句法： LIMIT # OFFSET #。
經常用到在數據庫中查詢中間幾條數據的需求
比如下面的sql語句：
① selete * from testtable limit 2,1;
② selete * from testtable limit 2 offset 1;
注意：
1.數據庫數據計算是從0開始的
2.offset X是跳過X個數據，limit Y是選取Y個數據
3.limit X,Y 中X表示跳過X個數據，讀取Y個數據
這兩個都是能完成需要，但是他們之間是有區別的：
①是從數據庫中第三條開始查詢，取一條數據，即第三條數據讀取，一二條跳過
②是從數據庫中的第二條數據開始查詢兩條數據，即第二條和第三條。
原創文章，歡迎轉載，轉載請注明出處！
參考了以下鏈接：
[1]http://blog.csdn.net/tuenbotuenbo/article/details/7974909
[2]http://www.w3school.com.cn/sql/sql_top.asp
[3]http://www.server110.com/mysql/201310/2228.html
[4]http://www.cnblogs.com/yxnchinahlj/p/4096484.html