這裡我們將資料庫的優化，分為三個大的方面：
在資料庫優化的方向上，沒有什麼正規化是絕對的，我們要根據情況設計合理的表結構，一味地追求完美的三正規化是乙個錯誤且固執的想法！
分析：我們看，哪個更符合三正規化呢，明顯是第二個，因為第乙個設計有分值這個欄位的冗餘，也有得分的冗餘，這樣看第二個是合理的！
但是在實際考試中，每個專業和每個專業的考核標準不一樣，分值有可能完全不一樣，這時我們在第一場考試每個選擇題1分，但是第二場考試每個選擇題3分，難道我們要重新匯入乙個新的題庫嗎？明顯第二個要這麼做（知識其中乙個解決方法），這時就增加了資料量，也增加了處理難度！
由此可見，適當的反正規化更利於資料的儲存和檢索！
我們理解的索引，是資料庫什麼都不用改，建立索引之後就可以增加查詢效率的機制，但是，哪有百分百完美的解決方案，索引的建立，確實幫助我們較為有效地解決了查詢的問題，但是在增，刪，改的操作上，就不會那麼出力！關於怎麼解決這個問題，我們下邊會有討論！為了更好滴利用索引，我們要堅持幾個原則
原則一，索引字段必須最常用
原則二，多個索引，首個索引保證常用
原則三，索引字段能夠和其他字段明顯區分
這次我們要回歸三正規化，要對我們的表進行合理的劃分，對資料進行有效的分流，這裡主流的方法有兩種，水平劃分和垂直劃分。
我們用一張表的圖來理解這兩種的區別：
這裡的劃分手段也是多種多樣的，可以將表從邏輯和物理上都拆開，也可以邏輯上在一起，物理上是拆開的（類似於檢視和表之間的關係）！
乙個好的資料庫設計，要做到合適，這個問題就是空間利用合適，同樣是1萬條資料，本來這個資料就簡單16位就可以解決，如果用用32位的型別儲存整個空間就多出去一倍，檢索效率就會下降一半，這個例子告訴我們，合適的空間，就意味著更高地檢索效率！
我們的設計中，有時會用到非關係型資料，比如，我們怎麼處理，他是資料處理的一部分，但是sql又力不能及？怎麼辦？這時候我們可以單獨拿出這個問題，可以存在乙個資料夾下，但是資料就會暴露，我們這時就不要死守sql的陣營了，這時候可以考慮考慮去非關係型資料庫找找出路，思路就會一下子開啟！
初步的db設計，我們會想，改怎麼用資料語句，就怎麼用，改寫就寫，改查就差，但是，這是初級的水平，更高層次的發展，要綜合考慮，我們不一定寫入資料和處理資料同時進行。
舉個例子，比如考試，學生考試，學生的答題記錄的寫入和分值的計算還有統計的結果。我們應該分開進行，把資料庫的壓力，分到不同的時間，比如晚上，決不能影響這場考試的進行！
在程式建立之初，我們建立日誌系統時，應該考慮到以後的公升級和優化的問題，這時候建立個系統「慢日誌」顯得很有必要，為我們的系統建立個日誌，用來檢測sql語句的執行大於預定值的事件，讓我們在分析的時候能夠很好地通過這些日誌了解我們的系統，分析優化的部分。
除了「慢日誌」我們還要有「滿日誌」，用來記錄cpu利用率超過80%的時間及事件，讓我們對我們的系統有個全面清晰的認識！
如果我們想更好滴利用好我們的db，適當的實際，對系統進行整理是必要的，這時候，我們可以對資料進行乙個整體的全索引掃瞄，提高我們的效率！
這裡的內容是對資料庫的進一步優化，對資料庫的引數根據實際的情況進行調整，比如查詢超時，如果乙個查詢真的需要2分鐘，我們不妨就暫時將30秒的超時改為3分鐘，但是這是表象的解決，我們還是盡量做到資料的讀取控制在30秒內，給使用者乙個好的直觀感受！
還有引數是sql對記憶體的占用，我們有的系統是控制了sql對記憶體的占用，這時在優化查詢的同時，增大記憶體的占用就可以很好的解決我們的餓問題！
這是最後乙個問題，也是個耗錢的工程啊，乙個db軟體會公升級，電腦配置會更新換代，在合適的時機投入資金公升級自己公司的軟硬體系統，跟上世界潮流的變化才是硬道理！想想google的伺服器，為全世界人民服務，它也在時刻追被更新換代，有時候的資金投入恰恰是在進行成本控制！
在我們的學習中，我們最大的優勢是我們有錯誤可以犯！錯誤使我們印象深刻，在公司中，什麼是經驗，經驗就是我們不會犯大多數人都會犯的錯誤，所以在今後的學習中，要珍惜每次犯錯的機會，這是我們提高最快的地方！要珍惜每個為大家服務的機會，這是我們將要犯錯的地方！更要珍惜每次的現場學習，這是使我們永遠忘不了的地方！與大家分享，讓我們在走向大鳥的道路上，共同努力……
海量資料探勘 DB優化篇
這裡我們將資料庫的優化，分為三個大的方面 在資料庫優化的方向上，沒有什麼正規化是絕對的，我們要根據情況設計合理的表結構，一味地追求完美的三正規化是乙個錯誤且固執的想法！分析 我們看，哪個更符合三正規化呢，明顯是第二個，因為第乙個設計有分值這個欄位的冗餘，也有得分的冗餘，這樣看第二個是合理的！但是在實...
Oracle之優化篇 海量資料處理分析
筆者在實際工作中，有幸接觸到海量的資料處理問題，對其進行處理是一項艱鉅而複雜的任務。原因有以下幾個方面 一 資料量過大，資料中什麼情況都可能存在。如果說有10條資料，那麼大不了每條去逐一檢查，人為處理，如果有上百條資料，也可以考慮，如果資料上到千萬級別，甚至過億，那不是手工能解決的了，必須通過工具或...
Oracle之優化篇 海量資料處理分析
筆者在實際工作中，有幸接觸到海量的資料處理問題，對其進行處理是一項艱鉅而複雜的任務。原因有以下幾個方面 一 資料量過大，資料中什麼情況都可能存在。如果說有10條資料，那麼大不了每條去逐一檢查，人為處理，如果有上百條資料，也可以考慮，如果資料上到千萬級別，甚至過億，那不是手工能解決的了，必須通過工具或...