遇到1000萬數據表

最近遇到一個問題，就是單表數據過1000萬的存儲及查詢問題。舉個例子：1000萬的數據存在一個表中，欄位4-5個樣子，日常 開發中難免要做過濾、排序、分頁。如果把這幾個放在一起即要過濾又要排序，還要分頁那麼數據量大一些就會發現特別慢。

10多年前剛入行時就聽許多的人討論分頁，說什麼1000萬大表分頁存儲過程啥的。我之後一直工作中也沒怎麼遇到大數據量的開發工作，也真是慚愧啊，現在算是補補課吧。

1000萬數據分個頁吧

常用的資料庫產品對分頁都是有一些支持的，SQL語句肯定是OK的，同樣的問題在於如何高效。因為分頁查詢最大的問題在於查詢越往後的數據就越慢，因為要掃描的數據多。比如要查詢第9999900-10000000之前的記錄，就得將前面的數據找起。

為什麼會這樣呢？因為數據存在存儲介質里，是一種數據結構的，電腦通過指令來查找想要的數據就要有一種演算法，因為機器本身不知道你想要哪些數據。所以在數據寫入時的自然順序會在具體查找時變成麻煩。

換句話說，如果不在乎時間長短，那麼分頁查詢其實也沒多大事，大不行等個幾十秒也能出來數據。但現實是這很難被接受。所以現在有一些方法來加快這個過程。

比如人們就想出一個方法，在分頁查詢前記錄一下最後那頁的記錄的ID，然後查詢時直接從這個ID往後找數據，這種方法就解決了上面說的掃描問題，利用資料庫的數據檢索功能大大提升性能。

但這種方法有弊端，畢竟這個ID需要有順序啊，所取的數據也要是排過序的。但這說明想要提升效率方法是有的。

索引

我也不知道為什麼，一直以來就很懼怕資料庫方面的開發，我心中索引一直是個很複雜的東西，所以工作許久也沒有好好去學習一下。最近正好親密接觸了一下，才發現這東西真是好東西，也沒有想象中的那麼可怕。

所謂索引其實就是對特定的數據進行一種排序，然後與實際的數據記錄作映射，這樣的好處就是掃描數據時可以在一個有序的集合里查找，那麼演算法自然就簡單高效啦。在實際應用中也發現，通過索引查詢性能可以大幅提升。

當然索引並沒有這麼簡單，在什麼欄位上建索引很有講究，要根據實際業務情況來決定。這也就是為什麼一些電商的網站很少會有所有欄位都給排序的原因，因為這種成本是很昂貴的，甚至不可實現。大家註意淘寶是不是只給了特定的一些排序方式？

NoSQL

N多年前在NoSql開始流行時我就想學習來著，但可能是自己太懶的原因，直到今年我才開始瞭解了NoSql。目前聽的最多的Mongodb，甚至還有Redis也稱為Nosql，HBase之類的。它們有什麼特別呢？

我覺得Nosql最大的特點在於基於Key-value，這個特點的好處就是易於數據的擴展。傳統資料庫一旦遇到數據大了要麼就是分庫、分表，還有垂直，水平分的。但是NoSql天然解決這個問題，因為數據可以通過演算法進行橫向擴展。而且Nosql通常保存的數據結構也比較特別。另外Nosql通常是利用記憶體多於磁碟，這樣可以大大提升讀寫效率吧。

在K-V的基礎上提供一些類SQL的功能，就變得非常好用了。比如Mongodb可以實現過濾、排序、分頁等操作，這對於開發人員來說簡直神了，不用擔心跨庫或者跨表查詢啦。

但是也有弊端，比如join操作可能就沒這麼好玩啦。

SQL+NoSQL

最近看到國內有個團隊在做一處TiDB的開源項目，是基於google的論文開發的一套資料庫，特點就是相容mysql，同時又有nosql的高效和擴展性。這簡直更神了，我只能膜拜。只不過我連mongodb都還不會，所以這種好東西我暫時也沒有去瞭解。有空要學習學習吧。

結語

看起來複雜的東西其實道理不複雜，對，簡單的就是好的。