資料庫系統優化業務邏輯設計優化

當我們優化乙個系統時，有時發現一種情況就是自己修改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語句能使用到索引，或者增加冗餘字段減少其輸入和輸出資料，或者減少查詢資料（如計算靜態表），典型的如索引檢視，資料倉儲等。

資料庫系統優化 業務邏輯設計優化