當我們優化乙個系統時,有時發現一種情況就是自己修改sql,索引以及分割槽是不能解決效能問題的。這時你要考慮業務邏輯優化和表設計的重構。這兩點的確和設計結合的很緊密。
結合實際,我們先談談業務邏輯優化。
案例一:
我們的系統乙個文件模組,客戶點選時很慢,通過效能分析,是點選是去查詢資料庫,這時系統是通過hibernate來兩步處理:
1,計算該型別的文件數量總數。
這時顯示第二步的時間是很快的,只取20條記錄,但是計算該型別的所有總數很慢。系統的這時的輸入是很大的(計算該型別的全部文件,可能有幾萬篇資料),輸出就一條總數。這時因為業務邏輯複雜,即使建立索引,分割槽等等速度也是無法提高,因為不能真正做到索引覆蓋和分割槽消除。
客戶是點一下要等十幾秒是不能容忍的,這時可能輸入資料量很大下,資料庫很可能採用的是hash聯結,而且併發使用者一大,資料庫伺服器壓力很大。
這時常規的優化方法是沒有效果的。這時我們也發現,客戶其實對以前比較老的資料是不關心的,一般只是對近期的資料比較感興趣,所有我們就在查詢時預設設定半年的時間,然後在時間上設定聚集索引。並預設在此
時間上排序,使其使用合併聯結,減少輸入資料量,結果速度有明顯的提公升。
案例二:
我們在優化乙個客戶系統時,碰到一種情況,在客戶的一選擇功能時,客戶點選一下選擇相關資料,這時頁面要要幾分鐘才能出來,客戶很不滿意,這時修改sql和索引都沒有辦法,他的輸入的資料量也很大,和上面一下也要計算總數和取最新前幾條資料。
這時我們在查詢是關聯了人員,通過調查,發現客戶只對和自己相關的資料感興趣。也只是查詢自己相關的資料。所以這時在sql語句裡增加使用者id這條限制,同時在增加userid的索引,這樣一來,速度就大大提高。
總接:當然以上兩個案例,是從輸入入手,減少輸入和輸出的資料量,主要優化業務邏輯,達到優化系統。當然有些情況要和客戶確認和說服他們,有時他們不一定都認可,這時要說明這樣做的目的,相信他們也會理解。
表設計,在我們開發系統時已經確定,好的設計的確能大大提高效能,我們在優化系統時,碰到乙個比較麻煩的問題。
這條sql是判斷5個維度,乙個使用者id, 乙個機構id,乙個崗位id, 還有級別判斷和是否公共。sql語句裡有5個」or「組成查詢,表資料一大就表掃瞄,效能很差,但業務要求和系統要求這樣判斷。即使在表中這五個欄位都建索引,速度也不會快。太多"or"了,sql server 查詢分析器無法優化。
這時由於設計時: 使用者id,機構id,崗位id為3個只有乙個有資料。所以將這3個字段合併,較少"or"語句,讓資料庫能使用索引。
總結表設計是優化是讓sql語句能使用到索引,或者增加冗餘字段減少其輸入和輸出資料,或者減少查詢資料(如計算靜態表),典型的如索引檢視,資料倉儲等。
資料庫邏輯設計
資料庫設計包含需求設計 邏輯設計 物理設計和維護優化。為了設計出沒有資料冗餘和資料維護異常的資料結構,我們需要遵循以下規範 資料庫表中的所有欄位都只有單一屬性 單一屬性的列都是由基本的資料型別所構成 設計出來的表都是簡單的二維表 針對這個問題,我們怎麼破呢?我們對上面這個表拆分為3個表 學生表 課程...
資料庫 優化 資料庫系統配置優化 作業系統優化
資料庫是基於作業系統的,目前大多數mysql都是安裝在linux系統之上,所以對於作業系統的一些引數配置也會影響到mysql的效能,下面就列出一些常用的系統配置。優化包括作業系統的優化及mysql 的優化網路方面的配置,要修改 etc sysctl.conf 1 增加tcp支援的佇列數 net.ip...
資料庫的邏輯設計
oracle優化軟結構 能移出system表空間的東西盡量移出。將程式表和資料表分別存在不同的表空間。減少io操作 索引段不應該與其相關的表存在同乙個表空間。因為dml操作的時候同時會維護所以。alter index index name rebuild tablespace tablespace ...