db2資料庫優化

A. DB2資料庫更新數據緩慢，求優化建議

你這樣寫很不好，看起來寫的是一句sql，反而速度慢下來了。首先row_number() over() as rownum毫無必要，這樣來分頁效率不高。然後能不用*就不用*查詢。在大數據量和列很多的情況下，會慢很多。

而且你也說了，更新1W條數據需要半個小時。那麼可以採用存儲過程或者程序來訪問。這樣會快很多，推薦採用存儲過程，110W條數據，就算重建索引等，更新一條應該在200ms一下，一萬條，不會那麼久的。希望能幫助得到你。

你這樣寫sql語句，執行時間太久了，會造成假死現象，這樣很不好。

B. 基於DB2的資料庫應用系統的性能優化

摘要 結合DB 的使用經驗 從資料庫設計 查詢優化 並發控制 客戶/伺服器模式四個方面來討論資料庫應用系統性能優化的一些原則 方法等

關鍵詞 DB 性能優化 資料庫設計 查詢優化 並發控制 C/S模式

引言

DB 是一種高性能的大型關系資料庫管理系統 廣泛的應用在客戶/伺服器體系結構中 評價系統性能優化的標准有 吞吐量 響應時間 並行能力等 本文從資料庫的設計 查詢的優化 並發控制以及客戶/伺服器模式這四個角度來討論優化系統性能

設計資料庫

熟悉業務系統

對業務系統的熟悉程度對整個資料庫系統的性能有很大影響 一個對業務不熟悉的設計人員 盡管有豐富的資料庫知識 也很難設計出性能最佳的資料庫應用系統

規范化與非規范化

資料庫被規范化後 減少了數據冗餘 數據量變小 數據行變窄 這樣DB 的每一頁可以包括更多行 那麼每一區里的數據量更多 從而加速表的掃描 改進了單個表的查詢性能 但是 當查詢涉及多個表的時候 需要用很多連接操作把信息從各個表中組合在一起 導致更高的CPU和I/O花銷 那麼 有很多時候需要在規范化和非規范化之間保持平衡 用適當的冗餘信息來減少系統開銷 用空間代價來換取時間代價 有訂單信息表OrderDetail 它裡面記錄了投遞員信息 收款員信息 物品信息 價格策略 客戶信息… 這些信息分別在投遞員信息表 收款員信息表 物品信息表 價格策略表 客戶信息表中存放 如果按照規范化的要求 OrderDetail查詢時就必須要與這么多個表進行連接或者嵌套查詢 如果OrderDetail表中的數據量是在百萬級的 那麼一次查詢所需要的時間可能會達到好幾個小時 事實上 只要在設計時保證數據的邏輯有效性 很多信息都可以直接冗餘在OrderDetail表中 這些冗餘的數據能夠極大的提高查詢的效率 從而減少CPU和I/O操作

數據條帶化

如果一個表的記錄條數超過一定的規模 那麼最基本的查詢操作也會受到影響 需要將該表根據日期水平劃分 把最近 最經常用的數據和歷史的 不經常用的數據劃分開來 或是根據地理位置 部門等等進行劃分 還有一種劃分方式――垂直劃分 即把一個屬性列很多的表分割成好幾個小表 比如把經常用到的屬性放在一個表裡 不經常用到的屬性放在另一個表裡 這樣可以加快表的掃描 提高效率

選擇數據類型

對每一屬性選擇什麼樣的數據類型很大程度上依據表的要求 但是在不違背表要求的前提下 選擇適當的數據類型可以提高系統性能 比如有text列存放一本書的信息 用BLOB而不是character( ) BLOB存放的是指針或者文件參照變數 真正的文本信息可以放在資料庫之外 從而減少資料庫存儲空間 使得程序運行的速度提高 DB 提供了UDT（User Defined Datatypes）功能 用戶可以根據自己的需要定義自己的數據類型

選擇索引

索引是資料庫中重要的數據結構 它的根本目的就是為了提高查詢效率 現在大多數的資料庫產品都採用IBM最先提出的ISAM索引結構 使用索引可以快速 直接 有序的存取數據 索引的建立雖然加快了查詢 另一方面卻將低了數據更新的速度 因為新數據不僅要增加到表中 也要增加到索引中 另外 索引還需要額外的磁碟空間和維護開銷 因此 要合理使用索引

●在經常進行連接 但是沒有指定為外鍵的屬性列上建立索引

●在頻繁進行排序或分組（即進行group by或order by操作）的列上建立索引 按索引來排序或分組 可以提高效率

●在條件表達式中經常用到的不同值較多的列上建立檢索 在不同值少的列上不要建立索引

●如果待排序的列有多個 可以在這些列上建立復合索引（pound index） 即索引由多個欄位復合而成

查詢優化

現在的資料庫產品在系統查詢優化方面已經做得越來越好 但由於用戶提交的SQL語句是系統優化的基礎 很難設想一個原本糟糕的查詢計劃經過系統的優化之後會變得高效 因此用戶所寫語句的優劣至關重要 下面重點說明改善用戶查詢計劃的解決方案

． 排序

在很多時候 應當簡化或避免對大型表進行重復的排序 當能夠利用索引自動以適當的次序產生輸出時 可以避免排序的步驟 當以下的情況發生時 排序就不能省略

●索引中不包括一個或幾個待排序的列

●group by或order by子句中列的次序與索引的次序不一樣

●排序的列來自不同的表

為了避免不必要的排序 就要正確地增建索引 合理地合並資料庫表 盡管有時可能影響表的規范化 但相對於效率的提高是值得的 如果排序不可避免 那麼應當試圖簡化它 如縮小排序列的范圍等

． 主鍵

主鍵用整型會極大的提高查詢效率 而字元型的比較開銷要比整型的比較開銷大很多 用字元型數據作主鍵會使數據插入 更新與查詢的效率降低 數據量小的時候這點降低可能不會被注意 可是當數據量大的時候 小的改進也能夠提高系統的響應速度

． 嵌套查詢

在SQL語言中 一個查詢塊可以作為另一個查詢塊中謂詞的一個操作數 因此 SQL查詢可以層層嵌套 例如在一個大型分布式資料庫系統中 有訂單表Order 訂單信息表OrderDetail 如果需要兩表關聯查詢

SELECT CreateUserFROM Order WHERE OrderNo IN(SELECT OrderNoFROM OrderDetail WHERE Price= )

在這個查詢中 找出報紙單價為 元的收訂員名單 下層查詢返回一組值給上層查詢 然後由上層查詢塊再根據下層塊提供的值繼續查詢 在這種嵌套查詢中 對上層查詢的每一個值OrderNo 下層查詢都要對表OrderDetail進行全部掃描 執行效率顯然不會高 在該查詢中 有 層嵌套 如果每層都查詢 行 那麼這個查詢就要查詢 萬行數據 在系統開銷中 對表Order的掃描占 ％ 對表OrderDetail的搜索占 ％ 如果我們用連接來代替 即

SELECT CreateUserFROM Order OrderDetailWHERE Order OrderNo=OrderDetail OrderNo AND Praice=

那麼對表Order的掃描占 ％ 對表OrderDetail的搜索占 ％

而且 一個列的標簽同時在主查詢和where子句中的查詢中出現 那麼很可能當主查詢中的列值改變之後 子查詢必須重新查詢一次 查詢嵌套層次越多 效率越低 因此應當盡量避免子查詢 如果子查詢不可避免 那麼要在子查詢中過濾掉盡可能多的行

． 通配符

在SQL語句中 LIKE關鍵字支持通配符匹配 但這種匹配特別耗費時間 例如 SELECT * FROM Order WHERE CreateUser LIKE M_ _ _ 即使在CreateUser欄位上建立了索引 在這種情況下也還是採用順序掃描的方式 Order表中有 條記錄 就需要比較 次 如果把語句改為SELECT * FROM Order WHERE CreateUser > M AND CreateUser < N 在執行查詢時就會利用索引來查詢 顯然會大大提高速度

． distinct

使用distinct是為了保證在結果集中不出現重復值 但是distinct會產生一張工作表 並進行排序來刪除重復記錄 這會大大增加查詢和I/O的操作次數 因此應當避免使用distinct關鍵字

． 負邏輯

負邏輯如!= <> not in等 都會導致DB 用表掃描來完成查詢 當表較大時 會嚴重影響系統性能 可以用別的操作來代替

． 臨時表

使用臨時表時資料庫會在磁碟中建立相應的數據結構 因為內存的訪問速度遠遠大於外部存儲器的訪問速度 在復雜查詢中使用臨時表時 中間結果會被導入到臨時表中 這種磁碟操作會大大降低查詢效率 另外 在分布式系統中 臨時表的使用還會帶來多個查詢進程之間的同步問題 所以 在進行復雜查詢時最好不要使用臨時表

． 存儲過程

DB 中的Stored Procere Builder可以產生存儲過程 運行並測試存儲過程 存儲過程可以包含巨大而復雜的查詢或SQL操作 經過編譯後存儲在DB 資料庫中 用戶在多次使用同樣的SQL操作時 可以先把這些SQL操作做成存儲過程 在需要用到的地方直接引用其名字進行調用 存儲過程在第一次執行時建立優化的查詢方案 DB 將查詢方案保存在高速緩存里 以後調用運行時可以直接從高速緩存執行 省去了優化和編譯的階段 節省了執行時間 從而提高效率和系統利用率

最優的查詢方案按照某些標准選擇往往不可行 要根據實際的要求和具體情況 通過比較進行選擇 DB 提供的Query Patroller可以對不同的查詢方案的查詢代價進行比較 通過追蹤查詢語句 返回查詢不同階段的系統開銷 從而作出最佳選擇 DB 提供的Performance Monitor也對整個資料庫系統的性能進行監控 包括I/O時間 查詢次數 排序時間 同步讀寫時間等等

資料庫系統的並發控制也能影響系統性能 多個用戶的同時操作可能導致數據的不一致性 DB 為了防止同時修改造成數據丟失和訪問未被提交的數據 以及數據的保護讀 採用Lock機制來實現控制

C. 如何優化一個有100萬條記錄的資料庫表

可以採取兩個手段：
第一：將資料庫表拆分到不同的庫中，比如 tblMEMBER 就可以拆分到 DB1 與 DB2 中去。 實際上，可以拆分到 DB001 ... DB100 甚至更多的庫中間去。 DB1 與 DB2 最好不在一塊硬碟上。

第二：如果更大量級的數據，則最好拆分到不同的資料庫伺服器中去。 資料庫的拆分帶來的是查詢等操作的復雜性。簡單地可以通過 hash 或者 按序號 匹配不同的資料庫。復雜一些，應該設置一個獨立的應用伺服器（軟體）協調其中的操作。

D. db2 merge 操作的優化問題。

easy .
1： number加上索引 ；
2： 查詢語句加上with ur 指定隔離級別可以避免鎖表

另外：number加上索引之後也就加快delete操作的效率

E. 如何使用 REORG 和 RUNSTATS 命令優化資料庫性能

當資料庫里某張表上有大量插入操作時，需要在表上做 RUNSTATS 命令保證資料庫掌握准確的統計信息。

當資料庫里某張表中的記錄變化很大時（大量插入、刪除、更新操作），需要在表上做 REORG 和 RUNSTATS 一組維護操作來優化查詢的性能。有的表，可能初始化後從來都不會有數據量變化，就只需要做一次維護；有的表，一天之內的變化就很大，每天需要做多次維護。

注意，針對資料庫對象的大量操作，如反復地刪除表，存儲過程，會引起系統表中數據的頻繁改變，在這種情況下，也要考慮對系統表進行REORG操作。

一個完整的 REORG 表的過程應該是由下面的步驟組成的：

RUNSTATS -> REORGCHK -> REORG -> RUNSTATS -> BIND 或 REBIND

0 執行下面命令前要先連接資料庫

1 RUNSTATS

由於在第二步中 REORGCHK 時可以對指定的表進行 RUNSTATS 操作(在 REORGCHK 時指定 UPDATE STATISTICS)，所以第一步是可以省略的。如果知道哪些特點的表有數據變化，又可以只執行第一步而省略第二步。

如果表名為 DB2INST1.STAFF，表上有索引，可以執行下面的 RUNSTATS 操作：

db2 runstats on table db2inst1.staff with distribution and detailed indexes all

2 REORGCHK

REORGCHK是根據統計公式計算表是否需要重整。

對於每個表有3個統計公式，對索引有5個統計公式(版本8)，如果公式計算結果該表需重整，在輸出的 REORG 欄位中相應值為*，否則為-。

如果資料庫中數據量比較大，在生產系統上要考慮 REORGCHK 的執行時間可能較長，需安排在非交易時間執行。

可以分為對系統表和用戶表兩部分分別進行 REORGCHK：

1) 針對系統表進行REORGCHK

db2 reorgchk update statistics on table system

使用 UPDATE STATISTICS 參數指定資料庫首先執行 RUNSTATS 命令。

2) 針對用戶表進行 REORGCHK

db2 reorgchk update statistics on table user

根據統計公式的計算結果（是否有 *），考慮是否必要對表進行 REORG。注意，某些小表的結果可能由於統計信息過少而不準確。

3 REORG TABLE

執行 REORG 可以考慮分為表上有索引和沒有索引兩種情況：

1) 如果表上有索引

如表名為 DB2INST1.STAFF，索引名為 DB2INST1.STAFF，

REORG 表：

db2 reorg table db2inst1.staff index db2inst1.istaff use tempspace1

建議 REORG 時可以使用USE參數指定數據重排時使用的臨時表空間。如果不指定， REORG 工作將會在表所在表空間中原地執行。

如果表上有多個索引，INDEX 參數值請使用最為重要的索引名。

REORG 索引：

db2 reorg indexes all for table db2inst1.staff

2) 如果表上沒有索引

如表名為DB2INST1.STAFF, SYSIBM.SYSTABLES

db2 reorg table db2inst1.staff use tempspace1

db2 reorg table sysibm.systables use tempspace1

4 RUNSTATS

參見步驟 1。

5 (可選) 上面命令完成後可以重復第二步，檢查 REORG 的結果，如果需要，可以再次執行 REORG 和 RUNSTATS 命令。

6 BIND 或 REBIND

RUNSTATS 命令運行後，應對資料庫中的 PACKAGE 進行重新聯編，簡單地，可以使用 db2rbind 命令來完成。

例如，如果資料庫名為 SAMPLE，執行：

db2rbind sample -l db2rbind.out

F. 資料庫軟體的DB2

IBM公司研製的一種關系型資料庫系統。DB2主要應用於大型應用系統，具有較好的可伸縮性，可支持從大型機到單用戶環境，應用於OS/2.Windows等平台下。 DB2提供了高層次的數據利用性、完整性、安全性、可恢復性，以及小規模到大規模應用程序的執行能力，具有與平台無關的基本功能和SQL命令。DB2採用了數據分級技術，能夠使大型機數據很方便地下載到LAN資料庫伺服器，使得客戶機/伺服器用戶和基於LAN的應用程序可以訪問大型機數據，並使資料庫本地化及遠程連接透明化。 它以擁有一個非常完備的查詢優化器而著稱，其外部連接改善了查詢性能，並支持多任務並行查詢。 DB2具有很好的網路支持能力，每個子系統可以連接十幾萬個分布式用戶，可同時激活上千個活動線程，對大型分布式應用系統尤為適用。除了它可以提供主流的OS/390和VM操作系統，以及中等規模的AS/400系統之外，IBM還提供了跨平台（包括基於UNIX的LINUX，HP-UX，SunSolaris，以及SCOUnixWare；還有用於個人電腦的OS/2操作系統，以及微軟的Windows 2000和其早期的系統）的DB2產品。DB2資料庫可以通過使用微軟的開放資料庫連接（ODBC）介面，Java資料庫連接（JDBC）介面，或者CORBA介面代理被任何的應用程序訪問。7月14日，IBM全球同步發布了一款具有劃時代意義的資料庫產品——DB2 9（「DB2」是IBM資料庫產品系列的名稱）。而這款新品最大特點即是率先實現了可擴展標記語言（XML）和關系數據間的無縫交互，而無需考慮數據的格式、平台或位置。DB2的前世今生和未來：對於每個最終站在獎台上淚水盈面的奧運冠軍來說，為此刻他或她也許已經付出了5年甚至10年的艱苦努力。相比這些人類的冠軍們，這個世界還有另外一種意義上的冠軍，它們雖沒有淚水，卻依然在歷史上留下了非凡的軌跡—DB2就是這類冠軍中的一員。這個資料庫領域里當之無愧的冠軍，已用了足足25年來描繪它的軌跡。紀念IBM DB2的誕生BM DB2已經25周歲拉！

G. 優化SQL 查詢：如何寫出高性能SQL語句

1、深入理解資料庫的工作原理和數據存儲的方式，不同的資料庫的工作原理是不同的，mysql oracle db2等等都是不同的，更不要說一些nosql資料庫和newsql資料庫了。
2、理解sql語句檢索數據的方式。
3、理解索引，知道怎樣的欄位建立怎樣的索引，索引能做什麼，不能做什麼，合理的建立欄位。
4、合理的拆分和合並表，數據放在一張表裡面查詢肯定比放在多張表裡面級聯查詢要快。
5、會查看執行任務，任何資料庫都有查看執行任務的方法，包括nosql資料庫和newsql資料庫已經一些大數據資料庫；同時還要會分析執行任務，分析主要是所以的使用效率和欄位數據的檢索方式。
6、sql語句只是性能優化的簡單方面，性能優化是從整體應用架構開始體現的，優化sql並不能夠解決根本問題，當數據量達到一定級別以後，數據就不能使用關系型資料庫，而要使用大數據資料庫，這樣sql就無用了。
7、不要刻意專注sql本身，sql只是一種查詢語言，它本身與性能無關，性能優化的本質在於對存儲方式和查詢檢索過程的深入理解。
8、任何系統功能業務的准確性至上，首先保證功能的正確性再考慮性能優化，如果功能就是數據量大，業務復雜，必須要用到低性能sql的檢索方式，那麼你只能妥協，否則就要棄用sql和關系型資料庫另尋它路。