一般來說,對於做B/S架構的朋友來說,更有機會遇到高並發的數據庫訪問情況,因為現在WEB的普及速度就像火箭升空,同時就會因為高訪問量帶來一系列性能問題,而數據庫一直是用戶與商人之間交流的重要平台.用戶是沒有耐心忍受一個查詢需要用上10秒以上的，或者更少些，如果經常出現服務器死機或者是報查詢超時，我想那將是失敗的項目。做了幾年的WEB工作,不才,一直沒有遇到過大訪問量或者是海量數據的情況.這裡並不是說沒有海量數據的項目就不是好項目,要看項目的應用場合.
最近做項目時,偶然得到了這個機會,在我工作過程中,本人發現的單表最大記錄數高達9位數.像訂單表什麼的也有8位數.在查詢訂單的時候往往不能通過單表查詢就能解決,還要和其它相關表進行關聯查詢.如此關聯的表數據不大還好,一旦發生大表關聯大表,在查詢時就有可能出現慢長的等待。
主旨: 如何避免這種情況的發生呢?既然有了這樣的數據,需求還是要實現,這裡就我最近針對數據庫的優化過程,我分兩篇文章來說明下.
第一篇:如何盡量避免大表關聯.
第二篇:對大表進行分區.
背景:有兩張表:
1:訂單表：記錄用戶訂單的詳細信息.order,其中有一個會員卡號字段cardNo,訂單產生時間.
2:會員表：記錄會員相關信息.member,一個會員有一個代理號:proxyID,代理下面有許多的會員卡:cardNo,它們共用一個代理號.
兩表通過cardNo來相關聯.
需求:查詢一個用戶或者某些用戶某一時間段所有會員卡產生的訂單情況.
實現SQL:
select 字段 from order
inner join member on
order.cardNo=member.cardNo
and member.proxyID in('a-01',代理號二)
and 時間 between '20080101' and '20080131'
本人見解:我想一般的朋友看到這樣的需求大多會寫出這樣的查詢SQL,如果不喜歡用in或者認為in的性能不好的朋友可用union all 代替.SQL語句可以說簡單的不能再簡單了,本身並無問題,只是如果兩表的數據都在百萬以上,而且字段都特別多.此時如果只有索引的幫忙下並不一定能達到預期的效果.
解決方案一:利用表變量來替換大表關聯,表變量的作用域為一個批處理,批處理完了,表變量也會隨之失效,比起臨時表有它獨特的優點：不用手動去刪除表變量以釋放內存。
可行性:因為需求中的輸出字段大多來自訂單表,member表只起到數據約束的作用,和查詢用戶會員卡號的作用,所有可以先把代理的會員卡號先取到表變量中,然後利用帶有卡號的表變量和訂單表相關聯查詢.
declare @t table
(cardNo int)
insert @t
select cardNo from member where in('a-01',代理號二)
select 字段 from order
inner join @t on
[email protected] and 時間 between '20080101' and '20080131'
這裡我就不貼性能比較圖了,有興趣的朋友可以自己嘗試下.這種方法在查詢人員比較多的時候特別有幫助.它要開發員根據實際情況詳細比較,結果並不是統一的,不同的環境結果可能不一樣.希望大家理解.
解決方案二:利用索引視圖來提高大表關聯的性能.
可行性:一般在大表關聯時,我們的輸出列都遠小於兩表的字段合,像上面的member表只用到了其中的兩個字段(cardNo,proxyID).設想一下,此時的member表如果只有這兩個字段情況會不會好些呢?答案不言而喻.
視圖這個名詞在我以前對它的印象中,從來沒有認為視圖能優化查詢,因為我認為視圖對於數據庫來說就是一個虛假表,在數據庫中並無實際物理位置來存儲數據.對於用戶來說無非就是通過不同的視角來觀看結果.視圖數據的產生都是實時的,即當調用視圖時,自動擴展視圖,去運行裡面相應的select語句.後來才知道在2000後的版本中視圖分一般視圖和索引視圖,一般視圖就是沒有創建索引的我印象中的視圖.而創建了視圖後就稱為索引視圖.索引視圖是物理存在的,可在視圖上首先創建一個唯一的聚集索引,其它字段上也可創建非聚集索引.在不改變基礎表的情況下,起到了優化的效果.
CREATE VIEW memberVIEw
WITH SCHEMABINDING
AS
SELECT cardNo,proxyID from member
GO
--以會員卡號創建一個唯一聚集索引
CREATE UNIQUE CLUSTERED INDEX ix_member_cardNo
ON member (cardNo);
GO
注意:創建索引視圖要點:
1: CREATE VIEW memberVIEw後面要跟上WITH SCHEMABINDING
理由:? 使用 schemaname.objectname 明確識別視圖所引用的所有對象,而不管是哪個用戶訪問該視圖.
? 不會以導致視圖定義非法或強制 SQL Server 在該視圖上重新創建索引的方式,更改視圖定義中所引用的對象.
2:視圖上的第一個索引必須為 CLUSTERED 和 UNIQUE.
理由:必須為 UNIQUE 以便在維護索引視圖期間,輕松地按鍵值查找視圖中的記錄,並阻止創建帶有重復項目的視圖(要求維護特殊的邏輯).必須為 CLUSTERED,因為只有聚集索引才能在強制唯一性的同時存儲行.
3:以下情況可考慮創建索引視圖:
? 可預先計算聚合並將其保存在索引中,從而在查詢執行時,最小化高成本的計算.
? 可預先聯接各個表並保存最終獲得的數據集.
? 可保存聯接或聚合的組合.
4:基礎表的更新會引發索引視力的更新.
5:索引視圖的創建同時會帶來維護上的開銷.
理由:1:因為索引視圖是物理存在的.
2:要額外的維護索引.
實現:SQL:select 字段 from order
inner join memberVIEw on
order.cardNo=member.cardNo
and member.proxyID=in('a-01',代理號二)
and 時間 between '20080101' and '20080131'
總結:兩種解決方案來看,各有所長,一般可以優先考慮使用索引視圖來優化大表關聯.以上是本人對於如何盡量避免發生大表關聯所采取的措施,望大家指教.
