這裡我們將資料庫的優化,分為三個大的方面:
在資料庫優化的方向上,沒有什麼正規化是絕對的,我們要根據情況設計合理的表結構,一味地追求完美的三正規化是乙個錯誤且固執的想法!
分析:我們看,哪個更符合三正規化呢,明顯是第二個,因為第乙個設計有分值這個欄位的冗餘,也有得分的冗餘,這樣看第二個是合理的!
但是在實際考試中,每個專業和每個專業的考核標準不一樣,分值有可能完全不一樣,這時我們在第一場考試每個選擇題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條資料,那麼大不了每條去逐一檢查,人為處理,如果有上百條資料,也可以考慮,如果資料上到千萬級別,甚至過億,那不是手工能解決的了,必須通過工具或...