??????? 最近接到一個項目設計工作，這個項目曾經做過一期，但只上線了十幾個客戶端就出了很多難以克服的問題：數據同步問題（項目有客戶端數據庫以支持離線操作），查詢效率問題，占用網絡帶寬太大的問題等等，不得已只好重做了，今天說冗余之美，也根這個項目有一點的關系。

????? 在分析查詢效率時，發現該查詢的確復雜，連接了好向張表，而且在SELECT里還涉及大量計算，一個SQL語句長達數KB，忽略網絡因素，該語句在數據庫中單次查詢的時間就高達近2秒（ORACLE），后對其索引進行了近一步優化，但查詢時間還是超過了一秒，仔細分析，發現連接的好幾張表中有一些是VIEW，而且發現期中一個VIEW單查數據就得近一秒，初步鎖定的最大的問題，后發現其實該VIEW無非也是連接了一些表并進行了計算拼出了一些字段值，拼了不到十個字段，代價卻是如此之大，后續的優化方法就較簡單了，去掉沒必要的VIEW，而改用冗余字段的形式，這些冗余的插入和更新代價并不大，但卻大大提高了查詢的效率，最終的結果的單次查詢為200ms同內，達到了預期的效果。

??????? 類似的例子其時也時常遇到。比如最常見的用戶管理中，用戶與角色是多對多關系，角色與功能也是多對多，如果我們經常要用到用戶與功能的的對應關系，一般情況下就是連合查詢建了索引且數據量不大，并發數據不多的情況下不會有問題。但如果現有性能無法滿足了該怎么辦呢？建一張冗余表也許是一個好的選擇，因為這類數據變化并不大也不頻繁，因此維護冗余表的代價也不太大，但卻大大提高了查詢效率（至少一半以上）

??????? 拋開這些不說，在實際的代碼編寫中也會有一些例子，記得在高效C++書中也提到過over-eager evaluation概念，當然如果稱之為冗余計算也許并不合適，但實際上該思想就是利用可能冗余的計算來達到提高代碼效率的目的，一個應用是磁盤讀取時，如果用戶只要讀幾個字節，我們可能會將該字節前后的數據也一起讀進來，當然這也有一些權衡，比如說，某類業務明擺著用戶只關心那么一點點，你還去做更多的工作，那是白干，但在上面的例子中，根據經驗，當一個用戶需要數據的時候，往往也需要這些數據附近的數據，這樣，這種冗余讀取就帶來了很高的性能提升。

總結

以上是生活随笔為你收集整理的冗余之美的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。