數據庫系統優化--業務邏輯設計優化
導讀：當我們優化一個系統時，有時發現一種情況就是自己修改SQL，索引以及分區是不能解決性能問題的。這時你要考慮業務邏輯優化和表設計的重構。這兩點的確和設計結合的很緊密。下文中將會為大家詳細介紹這兩種優化。
業務邏輯優化
結合實際，我們先談談業務邏輯優化。
案例一：
我們的系統一個文檔模塊，客戶點擊時很慢，通過性能分析，是點擊是去查詢數據庫，這時系統是通過Hibernate來兩步處理：
1，計算該類型的文檔數量總數。
2，顯示最新文檔的前20篇文檔。
這時顯示第二步的時間是很快的，只取20條記錄，但是計算該類型的所有總數很慢。系統的這時的輸入是很大的(計算該類型的全部文檔，可能有幾萬篇數據)，輸出就一條總數。這時因為業務邏輯復雜，即使建立索引，分區等等速度也是無法提高，因為不能真正做到索引覆蓋和分區消除。
客戶是點一下要等十幾秒是不能容忍的，這時可能輸入數據量很大下，數據庫很可能采用的是hash聯結，而且并發用戶一大，數據庫服務器壓力很大。
這時常規的優化方法是沒有效果的。這時我們也發現，客戶其實對以前比較老的數據是不關心的，一般只是對近期的數據比較感興趣，所有我們就在查詢時默認設定半年的時間，然后在時間上設定聚集索引。并默認在此時間上排序，使其使用合并聯結，減少輸入數據量，結果速度有明顯的提升。
案例二：
我們在優化一個客戶系統時，碰到一種情況，在客戶的一選擇功能時，客戶點擊一下選擇相關數據，這時頁面要要幾分鐘才能出來，客戶很不滿意，這時修改sql和索引都沒有辦法，他的輸入的數據量也很大，和上面一下也要計算總數和取最新前幾條數據。
這時我們在查詢是關聯了人員，通過調查，發現客戶只對和自己相關的數據感興趣。也只是查詢自己相關的數據。所以這時在sql語句里增加用戶id這條限制，同時在增加userid的索引，這樣一來，速度就大大提高。
總結：
當然以上兩個案例，是從輸入入手，減少輸入和輸出的數據量，主要優化業務邏輯，達到優化系統。當然有些情況要和客戶確認和說服他們，有時他們不一定都認可，這時要說明這樣做的目的，相信他們也會理解。
表設計優化
表設計，在我們開發系統時已經確定，好的設計的確能大大提高性能，我們在優化系統時，碰到一個比較麻煩的問題。
原文： 數據庫重構(一)：字段合并
這條sql是判斷5個維度，一個用戶id, 一個機構id，一個崗位id, 還有級別判斷和是否公共。sql語句里有5個”or“組成查詢，表數據一大就表掃描，性能很差，但業務要求和系統要求這樣判斷。即使在表中這五個字段都建索引，速度也不會快。太多"OR"了，SQL Server 查詢分析器無法優化。
這時由于設計時： 用戶id，機構id，崗位id為3個只有一個有數據。所以將這3個字段合并，較少"Or"語句，讓數據庫能使用索引。
總結：
表設計是優化是讓sql語句能使用到索引，或者增加冗余字段減少其輸入和輸出數據，或者減少查詢數據(如計算靜態表)，典型的如索引視圖，數據倉庫等。
上文中通過實例來詳細介紹了兩種數據庫優化，即業務邏輯優化和表設計優化，用實例是將抽象的食物具體化，更利于大家的理解，希望大家都能從上文的介紹中收獲各自需要的。
【編輯推薦】
