遇到的問題

1、最初階段

系統中做了一個監控功能，用于記錄所有的請求數據，數據插入頻繁，量非常大，比如一天1000萬條。考慮到數據插入的效率，就使用內存KV緩存來保存。寫入過程是在接收到請求后放入到線程池中，然后線程池異步處理后寫入。到這問題基本上沒什么事情。

2、新的需求

后面數據保存了，就需要在運維系統中可以查詢到，所以這個緩存還必須是分布式的。于是就換成了redis，這樣系統都可以連接到。但是數據量太大，需要分頁查詢，這就有點頭痛了。還好redis是可以支持有序集合的，而且可以通過zrange來獲取指定范圍數據。

3、增加了需求

這些數據要在運維界面里還要可以按條件過濾，這個就非常頭疼啦，redis沒有條件過濾啊。即使過濾出來了數據要顯示在界面上必須分頁。

問題思考

最終突然發現如果存在數據庫里是不是很好解決？但是存在數據庫里就會有大量寫操作的問題，而且數據這么大，像Mysql單表很容易就破了。所以我想著是不是還是在nosql的基礎上解決。

這里就有幾個問題：大數據量的排序、查找過濾、分頁。

先不管這么多，如果使用Mysql的話，除了大表保存問題，查找、過濾、分頁功能都是直接使用sql實現的，開發起來簡單。

mysql

如果使用mysql存儲后，如果要查一些數據怎么整？先看下面的這段代碼：

SELECT t.* 
    from ofOffline1 t 
    ORDER BY t.creationDate desc
  LIMIT 1300000,100

這里最直接的就體現了兩點：先排序，然后取分頁的數據。好了，這里有幾個問題：

1、使用了*返回字段，全字段返回的問題就是要掃描全表
2、進行了ORDERBY排序，我測試的這個表只有幾百萬數據
3、最后分頁是取的130萬開始的100條，等于是要掃描130萬后才開始

我隨便跑了一下執行了：5.5秒左右。有沒有辦法讓它快一點呢？確實有，網上找找挺多的。

首先，看看只返回部分字段是不是快一些？

SELECT t.creationDate 
    from ofOffline1 t 
    ORDER BY t.creationDate desc
  LIMIT 1300000,100

上面的SQL語句，改造后，只返回一個字段，再執行。2.9秒了。

那么取1條數據的速度會不會快一些呢？

SELECT t.creationDate 
    from ofOffline1 t 
    ORDER BY t.creationDate desc
  LIMIT 1300000,1

執行上面的sql后發現時間還是2.9秒，這說明取1條的數據也是這么慢，那慢的肯定就是排序啦。

然后使用這一條取出來的數據作為條件，直接在集合中定位到分頁數據

SELECT ofOffline1.* FROM ofOffline1 WHERE ofOffline1.creationDate <(
SELECT t.creationDate 
    from ofOffline1 t 
    ORDER BY t.creationDate desc
  LIMIT 1300000,1
) 
ORDER BY ofOffline1.creationDate desc
LIMIT 100

這是網上查到的SQL，思路就是先使用子查詢定位到第130萬條記錄，然后從它開始取后面的99條。時間差不多3.9秒左右。這說明這樣的優化還是有效的。

使用一下索引
我想了想如果加個索引是不是可以提升性能呢？SQL中只使用了creationDate排序和過濾，那么就用它建個索引試試吧。

還是測試一下最簡單的那條SQL

SELECT t.* 
    from ofOffline1 t 
    ORDER BY t.creationDate desc
  LIMIT 1300000,100

結果是：5.5秒左右，沒變化

那么看看前面有子查詢的情況：

SELECT ofOffline1.* FROM ofOffline1 WHERE ofOffline1.creationDate <(
SELECT t.creationDate 
    from ofOffline1 t 
    ORDER BY t.creationDate desc
  LIMIT 1300000,1
) 
ORDER BY ofOffline1.creationDate desc
LIMIT 100

不錯，執行結果：0.599秒。

好吧，本文先到這，后面再學習一下mangodb，按理它會比較適合我們的場景。