大數據量實時統計排序分頁查詢的瓶頸不是函數（count，sum等）執行，
不是having, 也不是order by，甚至不是表join, 導致慢的原因就在於“數據量太大本身”
- 化整為零
就是將表划分為M份相互獨立的部分,可以是分表，也可以是不分表但冗余一個取模結果字段
實際結果是不分表比分表更加靈活，只需稍加配置，就可以動態切分大表，隨意更改M的大小。
將1條慢sql（大於30秒）拆分成為N條查詢速度巨快的sql(單條sql執行時間控制在20毫秒以內)
然后再web應用中以適當的線程數去並發查詢這些執行時間快的N條小sql再匯總結果
- 兩步查詢
第一步查詢中去並發執行這N條小sql, 只取排序字段和標識字段，其他字段一律丟棄
匯總結果后定位出當前頁面要顯示的pageNum條數據，再進行第二步查詢，取出頁面上需要展示的所有字段
- web應用自身計算與數據庫計算的折中
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秒之間。