一般來說,對於做b/s架構的朋友來說,更有機會遇到高併發的資料庫訪問情況,因為現在web的普及速度就像火箭公升空,同時就會因為高訪問量帶來一系列效能問題,而資料庫一直是使用者與商人之間交流的重要平台.使用者是沒有耐心忍受乙個查詢需要用上10秒以上的，或者更少些，如果經常出現伺服器宕機或者是報查詢超時，我想那將是失敗的專案。做了幾年的web工作,不才,一直沒有遇到過大訪問量或者是海量資料的情況.這裡並不是說沒有海量資料的專案就不是好專案,要看專案的應用場合.
最近做專案時,偶然得到了這個機會,在我工作過程中,本人發現的單錶最大記錄數高達9位數.像訂單表什麼的也有8位數.在查詢訂單的時候往往不能通過單錶查詢就能解決,還要和其它相關表進行關聯查詢.如此關聯的表資料不大還好,一旦發生大表關聯大表,在查詢時就有可能出現慢長的等待。
主旨: 如何避免這種情況的發生呢?既然有了這樣的資料,需求還是要實現,這裡就我最近針對資料庫的優化過程,我分兩篇文章來說明下.
第一篇:如何盡量避免大表關聯.
第二篇:對大表進行分割槽.
背景:有兩張表:
1:訂單表：記錄使用者訂單的詳細資訊.order,其中有乙個會員卡號字段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'
解決方案一:利用表變數來替換大表關聯,表變數的作用域為乙個批處理,批處理完了,表變數也會隨之失效,比起臨時表有它獨特的優點：不用手動去刪除表變數以釋放記憶體。
可行性:因為需求中的輸出字段大多來自訂單表,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
asselect 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'
如何應付表資料過大的查詢問題？
一般來說，對於做b s架構的朋友來說，更有機會遇到高併發的資料庫訪 問情況，因為現在web的普及速度就像火箭公升空，同時就會因為高訪問量帶來一系列效能問題，而資料庫一直是使用者與商人之間交流的重要平台。使用者是沒有耐心 忍受乙個查詢需要用上10秒以上的，或者更少些，如果經常出現伺服器宕機或者是報查詢...
post資料過大的問題
背景 當post到後端的資料過大時可能會遇到問題，由於springboot預設給tomcat的配置是資料大小為2m，所以大於此值時會報錯 博主的是客戶端收到的是302然後socket斷連 原始tomcat配置post資料大小的配置 maxpostsize引數即為限制post資料大小的引數，單位是by...
如何優化大表的連線查詢 如何測試資料庫查詢優化器
我一直認為，查詢優化器 query optimizer，後面簡稱優化器 一直是資料庫領域 top 級別的 hardcore 技術，自己也一直嘗試去深入理解，但每每看到 tidb 裡面那一大坨 plan 的 我就望而生畏了，就像是 可遠觀而不可褻玩焉 但雖然很難理解，還是能通過方式去理解優化器的，乙個...