A. 求教，MYSQL大數據量分頁哪些好辦法
分頁查詢一般 DBA 想到的辦法是在某個（如ID，create_time)欄位上加組合索引。這樣條件排序內都能有效的利容用到索引，性能迅速提升。
因為如果當 LIMIT 子句變成 「LIMIT 1000000,10」 時，你會抱怨：我只取10條記錄為什麼還是慢？
要知道資料庫也並不知道第1000000條記錄從什麼地方開始，即使有索引也需要從頭計算一次。出現這種性能問題，多數情形下是程序員偷懶了。在前端數據瀏覽翻頁，或者大數據分批導出等場景下，是可以將上一頁的最大值當成參數作為查詢條件的。SQL 重新設計如下：
SELECT *
FROM 表
WHERE create_time > '2017-07-04 09:00:00'
ORDER BY create_time limit 10;
這樣查詢時間基本固定，不會隨著數據量的增長而發生變化。
B. mysql 數據量大的表如何做分頁查詢
直接用limit start, count分頁語句， 也是我程序中用的方法：
select * from proct limit start, count
當起始頁較小時，查詢沒有性能問題，我們分別看下從10， 100， 1000， 10000開始分頁的執行時間（每頁取20條）， 如下：
select * from proct limit 10, 20 0.016秒
select * from proct limit 100, 20 0.016秒
select * from proct limit 1000, 20 0.047秒
select * from proct limit 10000, 20 0.094秒
我們已經看出隨著起始記錄的增加，時間也隨著增大， 這說明分頁語句limit跟起始頁碼是有很大關系的，那麼我們把起始記錄改為40w看下（也就是記錄的一般左右） select * from proct limit 400000, 20 3.229秒
再看我們取最後一頁記錄的時間
select * from proct limit 866613, 20 37.44秒
難怪搜索引擎抓取我們頁面的時候經常會報超時，像這種分頁最大的頁碼頁顯然這種時
間是無法忍受的。
從中我們也能總結出兩件事情：
1）limit語句的查詢時間與起始記錄的位置成正比
2）mysql的limit語句是很方便，但是對記錄很多的表並不適合直接使用。
C. MySQL大數據量分頁查詢方法及其優化
使用子查詢優化大數據量分頁查詢
這種方式的做法是先定位偏移位置的id，然後再往後查詢，適用於id遞增的情況。
使用id限定優化大數據量分頁查詢
使用這種方式需要先假設數據表的id是連續遞增的，我們根據查詢的頁數和查詢的記錄數可以算出查詢的id的范圍，可以使用 id between and 來查詢：
當然了，也可以使用in的方式來進行查詢，這種方式經常用在多表關聯的情況下，使用其他表查詢的id集合來進行查詢：
但是使用這種in查詢方式的時候要注意的是，某些MySQL版本並不支持在in子句中使用limit子句。
參考 sql優化之大數據量分頁查詢（mysql） - yanggb - 博客園 (cnblogs.com)
D. 一千萬條數據的表, 如何分頁查詢
數據量過大的情況下, limit offset分頁會由於掃描數據太多而越往後查詢越慢。可以配專合當前頁最後一條ID進行查詢, SELECT * FROM TABLE WHERE id > #{ID} LIMIT #{LIMIT}。當屬然, 這種情況下ID必須是有序的, 這也是有序ID的好處之一。
E. （問題解決再追加100分）sql server存儲過程實現查詢數據條數過大，分頁查詢怎麼實現
按說5-8w這樣數量級的數據沒有問題，寫入Excel是布比較耗性能，主要還是要通過優化寫入Excel的代碼效率上去考慮。你可以考慮利用分批查詢寫入的方式來避免一次寫太多的數據到Excel：將你的查詢結果分段，比方你的語句中能不能用時間來認為分段，每次返回部分結果。
回到你的問題，對大數據量查詢的解決方案有以下兩種：
（1）、將全部數據先查詢到內存中，然後在內存中進行分頁，這種方式對內存佔用較大，必須限制一次查詢的數據量。
（2）、採用存儲過程在資料庫中進行分頁，這種方式對資料庫的依賴較大，不同的資料庫實現機制不通，並且查詢效率不夠理想。以上兩種方式對用戶來說都不夠友好。
2．解決思路
通過在待查詢的資料庫表上增加一個用於查詢的自增長欄位，然後採用該欄位進行分頁查詢，可以很好地解決這個問題。下面舉例說明這種分頁查詢方案。
（1）、在待查詢的表格上增加一個long型的自增長列，取名為「queryId」,mssql、sybase直接支持自增長欄位，oracle可以用sequence和trigger來實現。然後在該列上加上一個索引。
添加queryId列的語句如下：
Mssql: [QUERYID] [bigint] IDENTITY (1, 1)
Sybase: QUERYID numeric(19) identity
Oracle:
CREATE SEQUENCE queryId_S
INCREMENT BY 1
START WITH 1
MAXVALUE 999999999999999 MINVALUE 1
CYCLE
CACHE 20
ORDER;
CREATE OR REPLACE TRIGGER queryId_T BEFORE INSERT
ON "test_table"
FOR EACH ROW
BEGIN
select queryId_S.nextval into :new.queryId from al;
END;
（2）、在查詢第一頁時，先按照大小順序的倒序查出所有的queryId，
語句如下：select queryId from test_table where + 查詢條件 +order by queryId desc 。
因為只是查詢queryId欄位，即使表格中的數據量很大，該查詢也會很快得到結果。然後將得到的queryId保存在應用伺服器的一個數組中。
（3）、用戶在客戶端進行翻頁操作時，客戶端將待查詢的頁號作為參數傳遞給應用伺服器，伺服器通過頁號和queyId數組算出待查詢的queyId最大和最小值，然後進行查詢。
算出queyId最大和最小值的演算法如下,其中page為待查詢的頁號，pageSize為每頁的大小，queryIds為第二步生成的queryId數組：
int startRow = (page - 1) * pageSize
int endRow = page * pageSize - 1;
if (endRow >=queryIds.length)
{
endRow = this.queryIds.length - 1;
}
long startId =queryIds[startRow];
long endId =queryIds[endRow];
查詢語句如下：
String sql = "select * from test_table" + 查詢條件 + "(queryId <= " + startId + " and queryId >= " + endId + ")";
3．效果評價
該分頁查詢方法對所有資料庫都適用，對應用伺服器、資料庫伺服器、查詢客戶端的cpu和內存佔用都較低，查詢速度較快，是一個較為理想的分頁查詢實現方案。經過測試，查詢4百萬條數據，可以在3分鍾內顯示出首頁數據，以後每一次翻頁操作基本在2秒以內。內存和cpu佔用無明顯增長。
以上也僅僅是分頁查詢結果查看的問題，你需要寫入到Excel的話還需要考慮Excel寫入代碼的執行效率，這部分是很值得研究的。
F. 請教大數據量查詢怎麼分頁查詢
有些綁定控制項自帶分頁功能的。如果沒有就只能手寫分頁功能了。
G. 大數據量實時統計排序分頁查詢 優化總結
大數據量實時統計排序分頁查詢 (並發數較小時) 的瓶頸不是函數（count，sum等）執行，
不是having, 也不是order by，甚至不是表join, 導致慢的原因就在於「數據量太大本身」
就是將表劃分為M份相互獨立的部分,可以是分表，也可以是不分表但冗餘一個取模結果欄位
實際結果是不分表比分表更加靈活，只需稍加配置，就可以動態切分大表，隨意更改M的大小。
將1條慢sql（大於30秒）拆分成為N條查詢速度巨快的sql(單條sql執行時間控制在20毫秒以內)
然後再web應用中以適當的線程數去並發查詢這些執行時間快的N條小sql再匯總結果
第一步查詢中去並發執行這N條小sql, 只取排序欄位和標識欄位，其他欄位一律丟棄
匯總結果後定位出當前頁面要顯示的pageNum條數據，再進行第二步查詢，取出頁面上需要展示的所有欄位
PS：這一點是至關重要的，其他幾點都可以不看，這點是最關鍵的。慢慢解釋一下：
a) 第一種方式是把資料庫中所有記錄（只取排序欄位和標識欄位並且不做任何sum，count having order by等操作）
全部拉到web應用中，在web應用中完成所有的計算
b) 第二種方式是把資料庫中所有記錄做sum count having等操作之後的所有行數拉到web應用中，在web應用中完成剩餘計算
c) 第三種方式是把資料庫中所有記錄做sum count having order by等操作之後把limit後的數據拉到web應用中，
在web應用中對limit後的數據再計算
顯然，第一種方式 資料庫什麼活都不做只取數據 是不可行的。以lg_order_count_seller為例，1500萬行，
如果只算id, seller_id和order_count 這三個bigint類型，至少需要拉8*3*1500 0000 = 360000000=340M,
拉到內存中之後存儲需要8*4*15000000= 460M,這還不算List是的2的n次方這個特點和計算排序等的內存開銷，
不僅資料庫與web應用機器IO扛不住，就是應用自身恐怕也要OOM了。
第二種方式，所有記錄做sum count having等操作之後,由於是group by seller_id的，總得數據量變為100萬（就是賣家總數），
這樣子一來，共需要拉8*3*100 0000 = 23M,拉到內存之後，需要8*4*100 0000 = 30M, 再算上List是的2的n次方這個特點和
計算排序等的內存開銷也不會超過100M, IO的時間和內存開銷勉強可以考慮接受。
第三種方式，所有記錄做sum count having order by等操作之後把limit後的數據拉到web應用中，因為做了limit，所以，
數據量很小了，無論是IO還是內存開銷都已經很小了。可以忽略。
綜合以上三種，第三種方式適用於頁面的前n頁和後n頁，因為這個limit的數據量隨著頁數的增大而增大，
當大到每個切分後的小表的數據量時就轉為第二種方式了。
第二種方式適用於頁面的第[n+1, totaoPageNum-n]頁。
切分成N條小sql後並行執行時排序不穩定性的解決辦法
① 問題描述：
優化之前，還是是一條大慢sql查詢時，由於資料庫排序是穩定排序，
所以當兩條記錄排序欄位值相同時他們在頁面上的頁碼位置是固定的。
優化之後，當並行執行這N條小sql時，由於無法控制這些小sql的先後執行順序，
導致在web應用中當兩條記錄的排序欄位值相同時在頁面上的頁碼位置是隨機的。
② 解決辦法：
除了拉標識欄位(seller_id)和排序欄位(order_count_sum)之外，再取一個unique（id）的欄位，當兩條記錄的排序欄位值相同時，再用這個unique的欄位（在賣家監控中這個欄位是id）進行第二次排序.這樣就解決了排序不穩定的問題。
③ 也許，看到這里會有疑問，為什麼不用seller_id？seller_id也是唯一， 這樣子不是少取id這個欄位，減少IO了？
seller_id雖然也是唯一，可以輔助排序，但是不要忘記資料庫的排序規則是：
如果兩列的值相等，那麼序號在前的排在前面，這里的序號就是主鍵(自動生成，autoincrement),
如果用seller_id的話還是不能保證排序的穩定性，只能用主鍵id.
優先載入頁面上的主要元素，然後再去非同步載入次要元素，
反應在賣家監控頁面中，查數據和查頁頁碼的sql語句基本相同，是在競爭同一資源，
所以，需要做一個策略，優先把資源讓給查數，數據查完之後再去查頁碼。
限流
由於多線程取數據並沒有從本質上提高資料庫性能，所以必須針對大數據量實時統計排序分頁查詢做限流
我這里打個比方：食堂有6個窗口，物流團隊吃飯要買6個菜，平均每買1個菜需要1分鍾的時間，
如果派我一個人去一個窗口買的話需要6分鍾的時間
假如派6個人分別去6個窗口買這6個菜，只需要1分鍾的時間
但是，如果除了物流團隊，再來其他5個團隊呢，也就是說6個團隊每個團隊買6個菜共買36個菜，
這樣子有的團隊先買完，有的團隊後買完，但平均時間還是6分鍾。本質上沒有變化。
所以，對於特定的查詢條件，必須進行限流。讓每分鍾至多有6個團隊買菜，這樣子能使得情況變得不至於太糟糕。
從根本上改變現狀
這一點從目前來看只能是展望了，比如mysql資料庫換更為強大的oracle資料庫，
或更換InnoDb引擎為其他，或更換SATA硬碟為SSD 。。。。。。
從實踐效果來看，優化後的效果是很明顯的。
相同的查詢條件，原來一個頁面查詢時間由於超過60秒超時了，根據1-6點建議優化之後，查詢時間變為2秒至3.5秒之間。