SELECT CreateUser R
FROM Order
WHERE OrderNo IN & b
( SELECT OrderNo
FROM OrderDetail B
WHERE Price=0.5)
在這個查詢中，找出報紙單價為0.5元的收訂員名單。下層查詢返回一組值給上層查詢，然后由上層查詢塊再根據下層塊提供的值繼續查詢。在這種嵌套查詢中，對上層查詢的每一個值OrderNo，下層查詢都要對表OrderDetail進行全部掃描，執行效率顯然不會高。在該查詢中，有2層嵌套，如果每層都查詢1000行，那么這個查詢就要查詢100萬行數據。在系統開銷中，對表Order的掃描占82％，對表OrderDetail的搜索占16％。如果我們用連接來代替，即：
SELECT CreateUser xW
FROM Order,OrderDetail
WHERE Order.OrderNo=OrderDetail.OrderNo AND Praice=0.5
那么對表Order的掃描占74％，對表OrderDetail的搜索占14％。
而且，一個列的標簽同時在主查詢和where子句中的查詢中出現，那么很可能當主查詢中的列值改變之后，子查詢必須重新查詢一次。查詢嵌套層次越多，效率越低，因此應當盡量避免子查詢。如果子查詢不可避免，那么要在子查詢中過濾掉盡可能多的行。
4． 通配符
在SQL語句中，LIKE關鍵字支持通配符匹配，但這種匹配特別耗費時間。例如：SELECT * FROM Order WHERE CreateUser LIKE ‘M_ _ _’ 。即使在CreateUser字段上建立了索引，在這種情況下也還是采用順序掃描的方式，Order表中有1000條記錄，就需要比較1000次。如果把語句改為SELECT * FROM Order WHERE CreateUser >’M’ AND CreateUser <’N’，在執行查詢時就會利用索引來查詢，顯然會大大提高速度。
5． distinct
使用distinct是為了保證在結果集中不出現重復值，但是distinct會產生一張工作表，并進行排序來刪除重復記錄，這會大大增加查詢和I/O的操作次數。因此應當避免使用distinct關鍵字。
6． 負邏輯
負邏輯如!=、<>、not in等，都會導致DB2用表掃描來完成查詢。當表較大時，會嚴重影響系統性能，可以用別的操作來代替。
7． 臨時表
使用臨時表時數據庫會在磁盤中建立相應的數據結構，因為內存的訪問速度遠遠大于外部存儲器的訪問速度，在復雜查詢中使用臨時表時，中間結果會被導入到臨時表中，這種磁盤操作會大大降低查詢效率。另外，在分布式系統中，臨時表的使用還會帶來多個查詢進程之間的同步問題。所以，在進行復雜查詢時最好不要使用臨時表。
8． 存儲過程
DB2中的Stored Procedure Builder可以產生存儲過程，運行并測試存儲過程。存儲過程可以包含巨大而復雜的查詢或SQL操作，經過編譯后存儲在DB2數據庫中。用戶在多次使用同樣的SQL操作時，可以先把這些SQL操作做成存儲過程，在需要用到的地方直接引用其名字進行調用。存儲過程在第一次執行時建立優化的查詢方案，DB2將查詢方案保存在高速緩存里，以后調用運行時可以直接從高速緩存執行，省去了優化和編譯的階段，節省了執行時間，從而提高效率和系統利用率。
最優的查詢方案按照某些標準選擇往往不可行，要根據實際的要求和具體情況，通過比較進行選擇。DB2提供的Query Patroller可以對不同的查詢方案的查詢代價進行比較，通過追蹤查詢語句，返回查詢不同階段的系統開銷，從而作出最佳選擇。DB2提供的Performance Monitor也對整個數據庫系統的性能進行監控，包括I/O時間、查詢次數、排序時間、同步讀寫時間等等。
數據庫系統的并發控制也能影響系統性能。多個用戶的同時操作可能導致數據的不一致性，DB2為了防止同時修改造成數據丟失和訪問未被提交的數據，以及數據的保護讀，采用Lock機制來實現控制。
DB2中可以對表空間、表、表列和索引加鎖。鎖的粒度越大，鎖越簡單，開銷小，并發度低；粒度小，鎖機制復雜，開銷大，并發度高。大型系統在并發處理中如果遇到所要分配的資源處于鎖定狀態，系統會把進程掛起等待。如果一個很耗時的查詢操作工作于一個經常使用的表上，此時使用表一級鎖，意味著整個系統都要等待你的查詢結束以后才能夠繼續運行。所以在復雜查詢中，盡量避免使用表一級鎖。如果有這一類的需要該怎么辦呢？可以利用視圖來解決這一類問題。視圖避免了對表的直接操作，同時有能夠保證數據庫的高效運轉。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
