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