賽迪網 > IT技術 數據庫 > Sybase
  IT資訊搜索
 
IT產品搜索
[程式開發][網管世界][網路安全][數據庫技術]
[作業系統][嘉賓聊天·線上訪談][活動集錦]
[精彩專題][Symantec專區][訂閱IT技術週刊]
[開發論壇][網管論壇][安全論壇][數據庫論壇]
[作業系統論壇][Sybase專區][IBM dW技術專區]
[病毒求助][病毒與漏洞播報][文檔·源碼下載]

從三個方面進行講解如何適當優化"SQL" (1)

發佈時間:2008.07.04 04:35     來源:賽迪網    作者:Andy

【賽迪網-IT技術報道】如何適當優化SQL?

許多人在使用SQL時往往會陷入一個誤區,即太關注于所得的結果是否正確,而忽略了不同的實現方法之間可能存在的性能差異,這種性能差異在大型的或是複雜的數據庫環境中(如連線事務處理OLTP或決策支援系統DSS)中表現得尤為明顯。筆者在工作實踐中發現,不良的SQL往往來自於不恰當的索引設計、不充份的連接條件和不可優化的where子句。在對它們進行適當的優化後,其運行速度有了明顯地提高!下面我將從這三個方面分別進行總結:

為了更直觀地說明問題,所有實例中的SQL運行時間均經過測試,不超過1秒的均表示為(< 1秒)。

---- 測試環境--

---- 主機:HP LH II

---- 主頻:330MHZ

---- 記憶體:128兆

---- 作業系統:Operserver5.0.4

----數據庫:Sybase11.0.3

一、不合理的索引設計

例:表record有620000行,試看在不同的索引下,下面幾個 SQL的運行情況:

1.在date上建有一非個群集索引

select count(*) from record where date >

'19991201' and date < '19991214'and amount >

2000 (25秒)

select date,sum(amount) from record group by date

(55秒)

select count(*) from record where date >

'19990901' and place in ('BJ','SH') (27秒)

分析:

date上有大量的重復值,在非群集索引下,數據在物理上隨機存放在數據頁上,在範圍搜尋時,必須執行一次表掃描才能找到這一范圍內的全部行。

2.在date上的一個群集索引

select count(*) from record where date >

'19991201' and date < '19991214' and amount >

2000 (14秒)

select date,sum(amount) from record group by date

(28秒)

select count(*) from record where date >

'19990901' and place in ('BJ','SH')(14秒)

分析:

在群集索引下,數據在物理上按順序在數據頁上,重復值也排列在一起,因而在範圍搜尋時,可以先找到這個範圍的起末點,且只在這個範圍內掃描數據頁,避免了大範圍掃描,提高了查詢速度。

3.在place,date,amount上的組合索引

select count(*) from record where date >

'19991201' and date < '19991214' and amount >

2000 (26秒)

select date,sum(amount) from record group by date

(27秒)

select count(*) from record where date >

'19990901' and place in ('BJ, 'SH')(< 1秒)

分析:

這是一個不很合理的組合索引,因為它的前導列是place,第一和第二條SQL沒有引用place,因此也沒有利用上索引;第三個SQL使用了place,且引用的所有列都包含在組合索引中,形成了索引覆蓋,所以它的速度是非常快的。

4.在date,place,amount上的組合索引

select count(*) from record where date >

'19991201' and date < '19991214' and amount >

2000(< 1秒)

select date,sum(amount) from record group by date

(11秒)

select count(*) from record where date >

'19990901' and place in ('BJ','SH')(< 1秒)

分析:

這是一個合理的組合索引。它將date作為前導列,使每個SQL都可以利用索引,並且在第一和第三個SQL中形成了索引覆蓋,因而性能達到了最優。

5.總結:

缺省情況下建立的索引是非群集索引,但有時它並不是最佳的;合理的索引設計要建立在對各種查詢的分析和預測上。一般來說:

ヾ.有大量重復值、且經常有範圍查詢

(between, >,< ,>=,< =)和order by

、group by發生的列,可考慮建立群集索引;

ゝ.經常同時存取多列,且每列都含有重復值可考慮建立組合索引;

ゞ.組合索引要儘量使關鍵查詢形成索引覆蓋,其前導列一定是使用最頻繁的列。

二、不充份的連接條件:

例:表card有7896行,在card_no上有一個非聚集索引,表account有191122行,在 account_no上有一個非聚集索引,試看在不同的表連接條件下,兩個SQL的執行情況:

select sum(a.amount) from account a,

card b where a.card_no = b.card_no(20秒)

將SQL改為:

select sum(a.amount) from account a,

card b where a.card_no = b.card_no and a.

account_no=b.account_no(< 1秒)

1 2 下一頁>>


[ 發表評論 ] 字體[  ] [ 列印 ] [ 進入博客 ] [ 進入論壇 ]  [ 推薦給朋友 ]
  相關文章
  客戶需求反饋表
* 姓  名:
更多資料  了解方案  認識廠商
* 單位名稱:
* 聯繫電話:
* 電子郵件:
  賽迪推薦  
  手機·資費 ·新品·導購·評測·手機資費·寬帶
手機搜索  諾基亞 N73 MOTO Z6
  IT產品 ·筆記本·臺式機·伺服器·列印·投影
IT產品搜索 
  IT技術 ·開發·網管·安全·數據庫·作業系統
  資訊化 ·熱點·專題·訪談·週刊·方案案例
· 移動資訊化市場方興未艾 企業呼喚標準出臺
· 如何把握企業價值差異 避免CRM與SCM脫節
· 齊看四大廠商的SaaS動態 ERP案例分析
· 通方期貨CRM解決方案 方正電子公文系統
  IT博客 ·曾劍秋·項立剛·Java學習·網管
  IT技術論壇 ·開發·網管·安全·數據庫·系統