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

總結

以上是生活随笔為你收集整理的数据库系统优化--业务逻辑设计优化的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。