資料庫系統最佳化：商務邏輯設計最佳化

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