這是我剛進(jìn)入現(xiàn)在公司的時(shí)候所作的兩個(gè)測(cè)試報(bào)告之一，現(xiàn)公布出來(lái)，希望能對(duì)大家有所幫助。

隨著Microsoft的新一代關(guān)系數(shù)據(jù)庫(kù)系統(tǒng)SQL SERVER 2000（以下簡(jiǎn)稱(chēng)SQL2K）的發(fā)布，業(yè)界紛紛瞄準(zhǔn)了它的性能，尤其是針對(duì)于Oracle 8的性能比較。在一系列的測(cè)試中，SQL2K的的確確沒(méi)有辜負(fù)微軟對(duì)它的期望，獲得了相當(dāng)不錯(cuò)的成績(jī)，終于肩負(fù)起對(duì)抗Oracle，搶占高端數(shù)據(jù)庫(kù)市場(chǎng)的使命。

在關(guān)系數(shù)據(jù)庫(kù)的應(yīng)用當(dāng)中，當(dāng)隨著數(shù)量級(jí)或者容量級(jí)的數(shù)據(jù)急劇膨脹，很多數(shù)據(jù)庫(kù)的性能就飛速下降。因此在要求嚴(yán)格的應(yīng)用中，通常Oracle數(shù)據(jù)庫(kù)是作為用戶(hù)的首選，然而其高昂的價(jià)格卻讓人望而卻步。隨著SQL2K的到來(lái)，我們期待著Microsoft的SQL2K在大記錄量和大容量的情況下能有優(yōu)秀的表現(xiàn)。在此，我們針對(duì)SQL2K在這兩方面表現(xiàn)的性能作了測(cè)試。

測(cè)試計(jì)劃：

整個(gè)測(cè)試過(guò)程分為兩個(gè)部分，第一部分是數(shù)據(jù)庫(kù)大容量狀態(tài)下的執(zhí)行情況，第二部分是數(shù)據(jù)庫(kù)在大記錄量下的執(zhí)行情況。為了方便測(cè)試，我們編寫(xiě)了一個(gè)程序進(jìn)行各種數(shù)據(jù)庫(kù)操作，并進(jìn)行效率紀(jì)錄。

在兩個(gè)部分的測(cè)試中，我們分別在空數(shù)據(jù)庫(kù)環(huán)境下進(jìn)行各種數(shù)據(jù)庫(kù)基本操作，并記錄各個(gè)操作所需要的時(shí)間，然后再插入了大容量/大記錄量的數(shù)據(jù)后，再作同樣的操作并紀(jì)錄操作所需時(shí)間。最后對(duì)前后的時(shí)間進(jìn)行比較。當(dāng)然，由于網(wǎng)絡(luò)傳輸?shù)葐?wèn)題，可能導(dǎo)致一些誤差，但是這對(duì)我們的測(cè)試不會(huì)有太大的影響。

測(cè)試準(zhǔn)備：

★     測(cè)試環(huán)境：

OS：Windows 2000 Server

Database：Microsoft SQL Server 2000

Database Server：ADV2000

★     創(chuàng)建數(shù)據(jù)庫(kù)：

使用“企業(yè)管理器”在數(shù)據(jù)庫(kù)服務(wù)器上創(chuàng)建數(shù)據(jù)庫(kù)test，并且設(shè)置其大小為10GB，以避免在默認(rèn)容量大小下，隨著數(shù)據(jù)庫(kù)容量增加而導(dǎo)致服務(wù)器動(dòng)態(tài)分配磁盤(pán)空間的時(shí)候引起開(kāi)銷(xiāo)。

隨后再在test數(shù)據(jù)庫(kù)上創(chuàng)建一個(gè)Tab表，包含以下幾個(gè)字段：

（表一）

       ★ 并且我們使用Delphi 6編寫(xiě)了一個(gè)測(cè)試程序，采用ADO接口，連接數(shù)據(jù)庫(kù)服務(wù)器ADV2000。測(cè)試程序主要完成一下的功能：

1、  插入2000條數(shù)據(jù)（insert）

2、  選擇1000條數(shù)據(jù)（select）

3、  更新1000條數(shù)據(jù)（update）

4、  刪除1000條數(shù)據(jù)（delete）

5、  插入100，000條帶圖片數(shù)據(jù)（用于大容量測(cè)試）/插入1，000，000條不帶圖片測(cè)試（用于大記錄量測(cè)試）

測(cè)試過(guò)程

整個(gè)測(cè)試過(guò)程分為大容量數(shù)據(jù)測(cè)試和大記錄量數(shù)據(jù)測(cè)試：

大容量數(shù)據(jù)測(cè)試：

在大容量的數(shù)據(jù)測(cè)試中，我們通過(guò)插入圖片來(lái)使數(shù)據(jù)庫(kù)的容量膨脹，所以在以下的所有數(shù)據(jù)庫(kù)操作中，例如插入數(shù)據(jù)，都是指的插入帶圖片的數(shù)據(jù)。測(cè)試中選擇了一張41,958字節(jié)的圖片，并且大容量測(cè)試是在插入100,000條記錄以后的測(cè)試，因此我們可以大致估計(jì)當(dāng)時(shí)的數(shù)據(jù)表的容量為 (41958 * 100000) / (1024 * 1024) = 4001.43MB。

首先通過(guò)測(cè)試程序按順序進(jìn)行如下測(cè)試，在空表中“插入2000條紀(jì)錄->選擇1000條記錄->更新1000條記錄->刪除1000條記錄”，并記錄下各操作所需要的時(shí)間。測(cè)試結(jié)果如下圖和表中：

（圖一）

（表二）

上面的測(cè)試是在空數(shù)據(jù)表中進(jìn)行數(shù)據(jù)庫(kù)各種基本操作的測(cè)試，并且記錄了所需要的時(shí)間。然后我們插入100，000條帶有圖片的紀(jì)錄，使數(shù)據(jù)表的數(shù)據(jù)量膨脹到4001.43MB，接下來(lái)的工作就是測(cè)試大容量環(huán)境下的各種數(shù)據(jù)庫(kù)操作情況。

(圖二)

同樣按照以上的的步驟進(jìn)行測(cè)試：“插入2000條紀(jì)錄->選擇1000條記錄->更新1000條記錄->刪除1000條記錄”，并記錄下各操作的時(shí)間，如下：

（圖三）

（表三）

通過(guò)對(duì)比，我們發(fā)現(xiàn)：

在大記錄量（百萬(wàn)條記錄得數(shù)據(jù)量下），對(duì)SQL2K的影響并不算大，其性能影響也比較小，從下圖以看出來(lái)：

（圖四）

從這個(gè)柱狀圖可以反映出在需要大量時(shí)間的SQL操作中，SQL2K在大容量數(shù)據(jù)環(huán)境下的性能基本能保持，不會(huì)有太多的性能下降。但是從后面兩個(gè)只需要極短時(shí)間執(zhí)行的SQL操作從圖中無(wú)法反映出什么情況。

那讓我們通過(guò)計(jì)算再來(lái)看一下了，下面是在大容量數(shù)據(jù)環(huán)境下，同樣操作增加的時(shí)間與初始數(shù)據(jù)庫(kù)環(huán)境下所需時(shí)間的百分比：

（表四）

從表中中可以看出，Update和Delete操作的時(shí)候，好像在大容量環(huán)境下的性能損失嚴(yán)重。但是考慮到，因?yàn)榇嫒〉臄?shù)據(jù)庫(kù)服務(wù)器與客戶(hù)端位于不同的機(jī)器上，雖然通過(guò)100M的內(nèi)部網(wǎng)連接，但是由于網(wǎng)絡(luò)的問(wèn)題，導(dǎo)致了存取中網(wǎng)絡(luò)的延時(shí)。當(dāng)操作所需要的時(shí)間比較大的時(shí)候，這一點(diǎn)延時(shí)對(duì)時(shí)間比例影響不大，而一旦操作所需要的時(shí)間比較短的時(shí)候，這個(gè)延時(shí)就顯得尤為突出了。

對(duì)于Delete操作中的45.55%的性能損失，還有一個(gè)原因是，當(dāng)刪除紀(jì)錄的時(shí)候，數(shù)據(jù)庫(kù)會(huì)重建索引。當(dāng)數(shù)據(jù)量太大的原因下，導(dǎo)致了重建索引耗費(fèi)了較多的時(shí)間。

大記錄量數(shù)據(jù)測(cè)試：

在大記錄量環(huán)境下的測(cè)試，為了讓大容量測(cè)試不影響這次測(cè)試，首先我們徹底刪除掉大容量測(cè)試中使用的表Tab，并且重新創(chuàng)建一個(gè)完全一樣的新表Tab用于此次測(cè)試。

這個(gè)測(cè)試中的步驟和上一個(gè)測(cè)試基本一樣，同樣測(cè)試了空表狀況下的各個(gè)基本數(shù)據(jù)庫(kù)操作所需要的時(shí)間，但是，這個(gè)測(cè)試中我們沒(méi)有插入圖片，photo字段沒(méi)有插入任何東西，保持為空：“插入2000條紀(jì)錄->選擇1000條記錄->更新1000條記錄->刪除1000條記錄”，如下所示：

（圖五）

（表五）

在大容量數(shù)據(jù)環(huán)境下，我們插入的是100，000條帶有圖片的數(shù)據(jù)，從而導(dǎo)致了數(shù)據(jù)量達(dá)到了4001MB，而在這次的大記錄量環(huán)境下的測(cè)試，100，000條數(shù)據(jù)量可能已經(jīng)不能滿(mǎn)足我們的需要，我們希望能在更高數(shù)據(jù)量環(huán)境下進(jìn)行測(cè)試，以便于增大添入大數(shù)量級(jí)數(shù)據(jù)前后操作效率的差異，因此選擇了插入1，000，000條數(shù)據(jù)。

（圖六）

完成我們的大數(shù)量級(jí)的數(shù)據(jù)插入以后，進(jìn)行下一步的測(cè)試紀(jì)錄：“插入2000條紀(jì)錄->選擇1000條記錄->更新1000條記錄->刪除1000條記錄”，記錄下每一個(gè)操作所需要的時(shí)間，如下所示：

（圖七）

（表六）

比較兩種狀況下的測(cè)試結(jié)果：

（圖八）

       從第一個(gè)操作Insert來(lái)看，同樣SQL2K在大記錄量環(huán)境下性能損失不大，但是其它幾個(gè)操作結(jié)果從這個(gè)圖中依舊無(wú)法表現(xiàn)出來(lái)，我們只能通過(guò)增加時(shí)間百分比來(lái)作比較：

（表七）

通過(guò)增長(zhǎng)時(shí)間的百分比可以看出在這幾個(gè)操作中性能有所損失，但是我們卻無(wú)法派出是否是因?yàn)檫@些操作時(shí)間太短，因?yàn)榫W(wǎng)絡(luò)而引起的誤差。

四、測(cè)試結(jié)果

總結(jié)：雖然在測(cè)試中，因?yàn)楹芏嗟腟QL操作因?yàn)樗枰臅r(shí)間過(guò)短，而導(dǎo)致受到網(wǎng)絡(luò)傳輸?shù)挠绊?。但是我們?nèi)匀豢梢酝ㄟ^(guò)所需時(shí)間較長(zhǎng)的SQL操作進(jìn)行總結(jié)：

無(wú)論是在大容量（數(shù)GB單位）還是大記錄量（百萬(wàn)條記錄量）環(huán)境下，SQL SERVER 2000的性能都能保持較高的水平。一般情況下的性能損失不到5%，因此完全能夠滿(mǎn)足我們通常的實(shí)際應(yīng)用。

但是因?yàn)橛布葪l件的限制下，我們無(wú)法對(duì)更大容量（十GB、百GB乃至TB容量級(jí)），更大記錄量（千萬(wàn)，億級(jí)數(shù)據(jù)量）的環(huán)境下進(jìn)行測(cè)試。

總體說(shuō)來(lái)，在普通的企業(yè)級(jí)應(yīng)用中，SQL SERVER 2000已經(jīng)是能夠滿(mǎn)足我們的要求。