庫外替重的技術：

我覺得大家討論那篇文章寫得不怎么樣，至少技術上不怎么樣。
鏈表能夠用來大數據量查重，簡直是開玩笑，原因我不解釋了。

從計算機數學的角度上來說，什么查找算法最適合查重，似乎沒有爭議，B樹。
實際的應用中，B樹往往不是簡單的B樹運算，而是涉及了一些數據塊內存緩存、末層葉子節點的散列運算等。今天的各種商業數據庫，無論是高端Oracle，還是低端mysql，都是采用了B樹算法，這一點應該充分說明了這個算法的特點（高效率，低開銷）。

我不明白為什么大家總是在爭議是Oracle剔重技術好，還是實時數據庫性能好，這一點很是奇怪。Oracle的剔重技術相關于一套 B樹算法+鎖管理機制+Redo+Undo，這加起來的消耗至少是B樹算法本身的2倍。實時數據庫取決于它考慮的內容，你考慮得越復雜，你的性能也就越差，這一點毋庸置疑。作為商業軟件，他們這么考慮的確沒有任何錯誤。可是，實際計費軟件中需不需要呢？我們為什么要為我們不需要的功能增加消耗，增加成本呢？
    在針對計費領域，我們還可以考慮CRC或MD5的方法（這一點那篇文章中提到了）來減少關鍵字大小。還可以考慮按照服務號段、通話時間散列數據文件等等。

Ref：
===============================================================================
    一般的庫外剃重所占用的主機資源開銷相當于入庫所占用的主機資源開銷的比例是多少（可以用相應主機的價格比表示），如果這個比例超過5%，我認為數據庫唯一索引更經濟和更實用。
===============================================================================
我認為是只要有5%的差距，我就應該選擇庫外剔重。何況，實際上通過上述原理，應該很明顯的看出來這種性能的差距。

同樣的機器上，如果你文件剔重的速度沒有達到數據庫的4倍，不要認為Oracle太快了，而是你的程序太慢了，改進算法。（改進之前，建議你先學習數學知識，不要把那些理論上的什么二分查找，鏈表算法等簡單數據結構都搬過來，那都是理論，不可以作為實際用途的）

技術本身沒有好壞，關鍵在于你怎么用，在那里用。數據庫不錯，可是不能用作查重。B樹也不錯，可是，不能用作客戶查詢。