最近遇到乙個問題，就是單錶資料過1000萬的儲存及查詢問題。舉個例子：1000萬的資料存在乙個表中，欄位4-5個樣子，日常 開發中難免要做過濾、排序、分頁。如果把這幾個放在一起即要過濾又要排序，還要分頁那麼資料量大一些就會發現特別慢。
10多年前剛入行時就聽許多的人討論分頁，說什麼1000萬大表分頁儲存過程啥的。我之後一直工作中也沒怎麼遇到大資料量的開發工作，也真是慚愧啊，現在算是補補課吧。
常用的資料庫產品對分頁都是有一些支援的，sql語句肯定是ok的，同樣的問題在於如何高效。因為分頁查詢最大的問題在於查詢越往後的資料就越慢，因為要掃瞄的資料多。比如要查詢第9999900-10000000之前的記錄，就得將前面的資料找起。
為什麼會這樣呢？因為資料存在儲存介質裡，是一種資料結構的，計算機通過指令來查詢想要的資料就要有一種演算法，因為機器本身不知道你想要哪些資料。所以在資料寫入時的自然順序會在具體查詢時變成麻煩。
換句話說，如果不在乎時間長短，那麼分頁查詢其實也沒多大事，大不行等個幾十秒也能出來資料。但現實是這很難被接受。所以現在有一些方法來加快這個過程。
比如人們就想出乙個方法，在分頁查詢前記錄一下最後那頁的記錄的id，然後查詢時直接從這個id往後找資料，這種方法就解決了上面說的掃瞄問題，利用資料庫的資料檢索功能大大提公升效能。
但這種方法有弊端，畢竟這個id需要有順序啊，所取的資料也要是排過序的。但這說明想要提公升效率方法是有的。
我也不知道為什麼，一直以來就很懼怕資料庫方面的開發，我心中索引一直是個很複雜的東西，所以工作許久也沒有好好去學習一下。最近正好親密接觸了一下，才發現這東西真是好東西，也沒有想象中的那麼可怕。
所謂索引其實就是對特定的資料進行一種排序，然後與實際的資料記錄作對映，這樣的好處就是掃瞄資料時可以在乙個有序的集合裡查詢，那麼演算法自然就簡單高效啦。在實際應用中也發現，通過索引查詢效能可以大幅提公升。
當然索引並沒有這麼簡單，在什麼欄位上建索引很有講究，要根據實際業務情況來決定。這也就是為什麼一些電商的**很少會有所有欄位都給排序的原因，因為這種成本是很昂貴的，甚至不可實現。大家注意**是不是中給了特定的一些排序方式？
n多年前在nosql開始流行時我就想學習來著，但可能是自己太懶的原因，直到今年我才開始了解了nosql。目前聽的最多的mongodb，甚至還有redis也稱為nosql，hbase之類的。它們有什麼特別呢？
我覺得nosql最大的特點在於基於key-value，這個特點的好處就是易於資料的擴充套件。傳統資料庫一旦遇到資料大了要麼就是分庫、分表，還有垂直，水平分的。但是nosql天然解決這個問題，因為資料可以通過演算法進行橫向擴充套件。而且nosql通常儲存的資料結構也比較特別。另外nosql通常是利用記憶體多於磁碟，這樣可以大大提公升讀寫效率吧。
在k-v的基礎上提供一些類sql的功能，就變得非常好用了。比如mongodb可以實現過濾、排序、分頁等操作，這對於開發人員來說簡單神了，不用擔心跨庫或者跨表查詢啦。
但是也有弊端，比如join操作可能就沒這麼好玩啦。
最近看到國內有個團隊在做一處tidb的開源專案，是基於google的**開發的一套資料庫，特點就是相容mysql，同時又有nosql的高效和擴充套件性。這簡直更神了，我只能膜拜。只不過我連mongdodb都還不會，所以這種好東西我暫時也沒有去了解。有空要學習學習吧。
看起來複雜的東西其實道理不複雜，對，簡單的就是好的。
資料庫學習感悟
這學期的課還蠻有意思的，資料庫按往常來說會開成access，不過老師比較有趣，直接給我們開sql，說是同時把兩門學會，資料庫的課每週有一次，三節小課連上，我聽得還算認真把。反正就是一直在認真聽，沒有多少走神的時間。首先要明白什麼是資訊和資料，資訊就是對客觀世界的一種描述，而資料則是資訊的具體形式 但...
資料庫設計感悟
近期一直在負責乙個專案的資料庫設計，磕磕碰碰這麼久，總算將大致的資料結構設計完畢。整個設計階段走下來，主要有以下感想 熟悉系統業務。這是肯定要掌握的，對業務的熟悉度越高越能設計出合理的資料結構。掌握的至少包括功能模組的劃分 各個模組的臨界點以及各模組的關係。這裡清理清楚，就能儘量減少模組之間的耦合度...
資料庫小知識
1 判斷某錶是否存在某欄位，不存在返回 0，存在返回1 select count 1 from syscolumns where id object id 資料庫表名 and name 欄位名 2 查詢某錶某列中的最大值 select max fieldname fromtablename 3 判斷...