K/3 系統(tǒng)性能優(yōu)化解決方案?作者：詩歡

--重建索引速度較慢，請在系統(tǒng)空閑時間進(jìn)行

DBCC DBREINDEX(t_icitem)

DBCC DBREINDEX(t_item)

DBCC DBREINDEX(t_itemclass)

DBCC DBREINDEX(t_itemright)

DBCC DBREINDEX(t_user)

DBCC DBREINDEX(t_group)

go

if not exists(select 1 from sysindexes where name='ix_group_fgroupid')

create index ix_group_fgroupid on t_group(fgroupid)

go

if not exists(select 1 from sysindexes where name='ix_itemright_ftypeid')

create index ix_itemright_ftypeid on t_itemright(ftypeid)

go

1 SQL Server調(diào)整

當(dāng)用戶使用K3系統(tǒng)一段時間以后，發(fā)現(xiàn)系統(tǒng)的響應(yīng)時間越來越長。這種情形往往是由于賬套數(shù)據(jù)庫缺乏維護(hù)引起的。缺乏維護(hù)的數(shù)據(jù)庫會存在過多地碎片、過期的統(tǒng)計、隱含著可能的錯誤查詢結(jié)果的數(shù)據(jù)庫的邏輯和物理的不一致性，這些都會直接影響系統(tǒng)的性能。這里介紹解決上述賬套數(shù)據(jù)庫性能問題常用的方法。

1.1 使用DBCC語句發(fā)現(xiàn)和解決上述問題。

DBCC:?數(shù)據(jù)庫一致性檢查器。

打開SQL?查詢分析器?，執(zhí)行如下語句。

?

u?DBCC SHOWCONTIG?顯示指定表的數(shù)據(jù)和索引的有關(guān)數(shù)據(jù)碎片的信息DBCC SHOWCONTIG(表名[，索引名])

在有大的改動的表，引入數(shù)據(jù)的表，或者引起低效查詢的表上使用該語句。

例：DBCC SHOWCONTIG（’T_ITEM’）

u?DBCC DBREINDEX?重建指定數(shù)據(jù)庫中表的一個或多個索引。

例1：重建某個索引

???????????????????????????????DBCC?DBREINDEX?('T_ITEM',?uk_item2,?80)

例2：重建所有索引

DBCC DBREINDEX ('T_ITEM',’’,80)

?

u?DBCC SHOW_STATISTICS?顯示指定表上的指定目標(biāo)(例如一個索引名稱))的當(dāng)前分布統(tǒng)計信息。這些統(tǒng)計信息是被SQL Server查詢優(yōu)化器使用的DBCC SHOW_STATISTICS(表名，目標(biāo))

例：DBCC SHOW_STATISTICs('t_item','pk_item')

u?sp_updatestats & UPDATE STATISTICS?更新統(tǒng)計信息；?sp_updatestats?對當(dāng)前數(shù)據(jù)庫中所有?用戶定義的表運行 UPDATE STATISTICS.

使用UPDATE STATISTICS?語句的時機(jī)：在一個空表上創(chuàng)建一個索引，然后在以后應(yīng)用它。執(zhí)行TRUNCATE TABLE語句，然后在以后重新應(yīng)用該表。通過使用FULLSCAN或SAMPLE選項請求明細(xì)的索引統(tǒng)計信息。

例1. UPDATE STATISTICS T_ITEM

例2. UPDATE STATISTICS T_ITEM(PK_ITEM)

例?3.?USE?AIS20011203150410

EXEC sp_updatestats

?

u?DBCC CHECKTABLE?檢查指定表或索引視圖的數(shù)據(jù)、索引及?text?、ntext?和?p_w_picpath?頁的完整性。如果你相信一個指定的表可能被破壞了，這條命令非常有用。

u?DBCC CHECKDB?檢查指定數(shù)據(jù)庫中的所有對象的分配和結(jié)構(gòu)完整性。這條命令發(fā)現(xiàn)并修復(fù)數(shù)據(jù)庫地址分配和表內(nèi)部的全部錯誤。實際上，CHECKDB驗證數(shù)據(jù)庫內(nèi)部一切事物的完整性，但是，DBCC CHECKDB是一個耗費CPU和磁盤資源的操作，每個需要檢查的數(shù)據(jù)都必須首先從磁盤中讀出到內(nèi)存中。而且，DBCC CHECKDB 使用tempdb進(jìn)行排序 。要獲得較高的DBCC性能，推薦在下面的情況下運行DBCC：

?

l 在系統(tǒng)使用率較低的情況下運行CHECKDB；

l 確信當(dāng)前沒有執(zhí)行其他磁盤I/O操作，如磁盤備份操作；

l 將tempdb放在另一個磁盤系統(tǒng)上，或者放在一個快速磁盤子系統(tǒng)上；

l 為tempdb提供足夠的空間，運行DBCC帶上參數(shù)ESTIMATE ONLY（顯示執(zhí)行?DBCC CHECKDB?操作所需tempdb?空間的數(shù)量?），估計tempdb需要多少磁盤空間；

l 避免運行消耗大量CPU時間的查詢和批處理；

l 在DBCC命令運行時，減少事物活動；

l 使用NO_INFOMSGS選項（壓縮使用空間使用的信息和報告?）減少處理和tempdb使用率。

例：DBCC CHECKDB ('AIS20011203150410') WITH NO_INFOMSGS,ESTIMATEONLY

u?DBCC SQLPERF?提供有關(guān)所有數(shù)據(jù)庫中的事務(wù)日志空間使用情況的統(tǒng)計信息。日志文件的閑余空間的減少，會降低系統(tǒng)的性能。系統(tǒng)會在備份時日志截斷日志文件，所以要求用戶要制定一份良好的備份方案。

例：DBCC SQLPERF ( LOGSPACE )

1.2 使用數(shù)據(jù)庫維護(hù)計劃

使用數(shù)據(jù)庫維護(hù)計劃器是一種標(biāo)準(zhǔn)且方便的可對多個賬套數(shù)據(jù)庫同時設(shè)置維護(hù)任務(wù)維護(hù)模式。下面介紹其建立方法：

本方案所介紹的數(shù)據(jù)庫維護(hù)計劃側(cè)重于數(shù)據(jù)庫的優(yōu)化,即性能的提高。

1) 打開Enterprise Manager，展開服務(wù)器，展開管理,然后單擊數(shù)據(jù)庫維護(hù)計劃。從操作（Action）中選擇新建維護(hù)計劃?,可以看到圖4.1所示的歡迎屏幕，單擊下一步按鈕。

2) 選擇數(shù)據(jù)庫，選擇K3賬套所在的數(shù)據(jù)庫（可選一個或多個）。單擊下一步按鈕。

圖2 選擇數(shù)據(jù)庫

3) 更新數(shù)據(jù)庫優(yōu)化信息。選擇重新組織數(shù)據(jù)和索引頁，選擇使用原有可用空間重新組織頁面。選擇當(dāng)增長超過50MB時，從數(shù)據(jù)庫文件中刪除未使用空間，收縮后保留的可用空間為10%的數(shù)據(jù)空間。單擊下一步按鈕。

圖3更新數(shù)據(jù)庫優(yōu)化信息

4) 檢查數(shù)據(jù)庫完整性。選擇檢查數(shù)據(jù)庫完整性,包含索引以及嘗試修復(fù)所有小問題。單擊下一步。

圖4 檢查數(shù)據(jù)庫完整性

5) 指定數(shù)據(jù)庫備份計劃,備份在優(yōu)化方案中暫不考慮，跳過，單擊下一步。

圖5數(shù)據(jù)庫備份計劃

6) 指定事務(wù)日志備份計劃在優(yōu)化方案中暫不考慮，跳過，單擊下一步。

圖6指定事物備份計劃

7) 生成報表。選擇將報表寫入目錄中的文本文件，選擇刪除早于4周的報表文件?；蛘哌x擇將電子郵件報表發(fā)送到操作員，然后花時間閱讀這個報表，看看數(shù)據(jù)庫中是否有任何需要注意的問題。單擊下一步。

圖7生成報表

8) 維護(hù)計劃歷史記錄。

SQL Server每次運行時保持維護(hù)計劃的歷史?？梢詾g覽這個歷史，看看操作中何時遇到故障，然后確定故障原因。如果只有單臺機(jī)器，則要在本地服務(wù)器存放歷史紀(jì)錄，但如果網(wǎng)絡(luò)中又多臺機(jī)器，則要將歷史紀(jì)錄存放在中央服務(wù)器中，以便從各臺機(jī)器上方便的訪問。下面選擇缺省在本地存放1000行歷史紀(jì)錄。單擊下一步。

圖 8 維護(hù)歷史紀(jì)錄

9) 完成數(shù)據(jù)庫維護(hù)計劃向?qū)?。用于命名和檢查具體工作，在計劃名中輸入：K3賬套數(shù)據(jù)庫維護(hù)計劃。單擊完成按鈕生成計劃。

圖9 完成數(shù)據(jù)庫維護(hù)計劃向?qū)?/p>

1.3 發(fā)現(xiàn)死鎖和消除死鎖

死鎖形成的原因是不同的，有的死鎖系統(tǒng)可以自動地偵測和消除而另外一些則需要管理員調(diào)整請求

死鎖發(fā)生在兩個或多個進(jìn)程同時等待被其中一個進(jìn)程保留著的鎖。該進(jìn)程將不會釋放它保留的鎖直到它獲得被其它進(jìn)程保留的資源，反過來也一樣。當(dāng)一個死鎖被被確認(rèn)以后，SQL Server通過自動選擇可以立即打斷死鎖的線程來結(jié)束死鎖。

許多阻塞的問題發(fā)生在由于一個進(jìn)程保留鎖過長時間，引起一系列被阻塞的進(jìn)程等待其它進(jìn)程釋放鎖。SQL Server不能識別阻塞鎖并自動地解決它們,所以必須監(jiān)控阻塞鎖的存在并手工消除它。

在一個應(yīng)用中建立一個鎖的超時設(shè)置是一個防止阻塞鎖的方法。這允許應(yīng)用監(jiān)控阻塞鎖并回滾進(jìn)程而不是不確定地等待或阻塞語句的重提交。

下面，介紹手工消除死鎖的方法：

1) 系統(tǒng)長時間沒有響應(yīng)，可以在SQL查詢分析器中執(zhí)行系統(tǒng)存儲過程sp_lock?和sp_who?，?如圖所示，spid 57正在等待資源。

Spid?：系統(tǒng)進(jìn)程?ID

執(zhí)行命令：sp_who 57?可以得到關(guān)聯(lián)該進(jìn)程和鎖的用戶的登錄名稱，主機(jī)名稱和狀態(tài)等信息。

圖1. 運行sp_lock顯示的鎖信息

2) 轉(zhuǎn)到SQL Server Enterprise Manager,展開管理?，展開當(dāng)前活動，?展開鎖?/?進(jìn)ID?,如圖所示，spid57被spid56阻塞。

圖2. 顯示鎖的阻塞情況

3) 雙擊spid56,然后單擊取消進(jìn)程?（Kill Process）。

4) spid57阻塞解除。

2 硬件調(diào)整

硬件調(diào)整，是為K3系統(tǒng)的正常運行要求的工作量提供足夠的硬件資源的行動。要調(diào)整系統(tǒng)的硬件，就要決定可以為K3系統(tǒng)分配那些資源以改進(jìn)其性能，這些資源包括附加的內(nèi)存、CPU、I/O資源或所有這些資源的組合。調(diào)整系統(tǒng)性能的工作主要涉及決定應(yīng)該增加哪種資源，以及增加多少資源。

硬件調(diào)整是非常重要的，因為許多典型的性能問題是由不充足的或配置失當(dāng)?shù)挠布M件導(dǎo)致的。I/O子系統(tǒng)是一個數(shù)據(jù)庫調(diào)整的關(guān)鍵性部分。通過提供足夠的CPU、內(nèi)存與I/O資源?？梢员苊庠S多性能問題。

通過監(jiān)控相關(guān)的計數(shù)器，可以及時發(fā)現(xiàn)和解決引起系統(tǒng)性能降低的硬件問題。

2.1 控制內(nèi)存的使用

SQL Server 要求內(nèi)存是基于靜態(tài)內(nèi)存的需要：一是它自己的程序代碼和內(nèi)部數(shù)據(jù)結(jié)構(gòu)，例如內(nèi)核的工作負(fù)載，打開對象，鎖。二是數(shù)據(jù)高速緩存。

基于有效的系統(tǒng)資源和這些資源的競爭需要, SQL Server動態(tài)地獲得和釋放數(shù)據(jù)高速緩存。如果SQL Server的數(shù)據(jù)高速緩存需要更多的內(nèi)存，它查詢操作系統(tǒng)檢查是否有物理內(nèi)存可以利用。如果有，SQL Server在數(shù)據(jù)高速

存中使用它并且在內(nèi)存中保留先前讀到的數(shù)據(jù)。

為阻止Windows 2000頁面調(diào)度,SQL Server依賴Server activity增減數(shù)據(jù)高速緩存以保留4MB~10MB剩余物理內(nèi)存。對SQL Server不足的內(nèi)存分配或使用會引起數(shù)據(jù)連續(xù)地從硬盤上而不是高速緩存上讀取,這將降低系統(tǒng)的性能。

請觀察以下與內(nèi)存有關(guān)的計數(shù)器,以便及時發(fā)現(xiàn)和解決內(nèi)存上的問題。

使用工具:性能監(jiān)視器

監(jiān)控內(nèi)存和分頁的使用

對象:?計數(shù)器

描述

指導(dǎo)

Memory: Available Bytes

監(jiān)控被進(jìn)程執(zhí)行使用的有效字節(jié)數(shù)。

（可用物理內(nèi)存量）

這個計數(shù)器應(yīng)該總是大于5000KB;低值顯示物理內(nèi)存整體的缺乏和需要提高。

推薦值：大于4MB

Memory: Page/sec

為了訪問不在內(nèi)存中的頁而讀取或?qū)懭氪疟P的總頁數(shù)。

該計數(shù)器應(yīng)該從不持續(xù)大于零.如果值持續(xù)大于零，Windows 2000操作系統(tǒng)正在使用頁面調(diào)度來填充內(nèi)存.

推薦值：小于5

Process: Page Faults/sec/SQL Server Instance

缺頁/秒

處理器中的Page Faults的計數(shù)值。當(dāng)進(jìn)程所引用的虛擬內(nèi)存頁不在其主內(nèi)存的工作集中時，將發(fā)生頁錯誤。如果某一頁已在主內(nèi)存中（位與備用列表內(nèi)），或者它正被共享此頁的其他進(jìn)程使用，Page Fault 將不會導(dǎo)致系統(tǒng)從磁盤調(diào)入該頁。

這個計數(shù)器的高值表明過多的頁面調(diào)度和磁盤壓力,檢查是否是SQL Server 或其他的進(jìn)程引起過多的頁面調(diào)度。

隔離SQL Server 使用的內(nèi)存

Process: Working Set/SQL Server Instance

監(jiān)控用于SQL Server的一個實例的SQL Server進(jìn)程的內(nèi)存的

數(shù)量。

這個計數(shù)器應(yīng)該大于5000KB。當(dāng)這個計數(shù)器低于5000KB，沒有更多的內(nèi)存可供SQL Server 使用。

SQL Server: Buffer Manager: Buffer Cache Hit Ratio

高速緩存命中率

監(jiān)控高速緩存中不需從硬盤中讀取的頁的百分率,。不用區(qū)分用于高速緩存的是物理內(nèi)存還是頁面調(diào)度內(nèi)存。

這個計數(shù)器應(yīng)該大于90%，因為它顯示的是發(fā)現(xiàn)在內(nèi)存中的頁的數(shù)量。

SQL Server: Buffer Manger: Total Pages

監(jiān)控高速緩存中頁的總數(shù)量，包括數(shù)據(jù)庫，free和來自其他進(jìn)程的stolen頁。

低值顯示連續(xù)的磁盤輸入輸出或壓力.考慮增加更多的內(nèi)存.

SQL Server: Memory Manager Total Server Memory

監(jiān)控服務(wù)器正在使用的動態(tài)內(nèi)存的總的數(shù)量。

如果該計數(shù)器與可用的物理內(nèi)存比較持續(xù)高，則需加更多的內(nèi)存。

2.2 監(jiān)控線程和處理器的使用

優(yōu)化處理器性能是輸出量和響應(yīng)時間之間的一種平衡。

處理器的性能

當(dāng)你檢查處理器的使用，考慮SQL Server實例正在做的工作的類型。如果SQL Server正在做大量的計算，例如包含集合的查詢或綁定內(nèi)存這種不需要磁盤輸入輸出的查詢，100%的處理器時間可能被使用。

對于多處理器的系統(tǒng),你需要監(jiān)控每個處理器的這個計數(shù)器的分離的實例。確定所有處理器的平均值，可使

計數(shù)器：System:% Total Processor Time?。

線程

每個SQL Server的實例都是一個獨立的操作系統(tǒng)進(jìn)程，SQL Server2000的實例使用Windows線程，有時是纖程

去有效的管理并發(fā)的任務(wù)。

1) 一個進(jìn)程是一個應(yīng)用的實例，例如SQL Server并且能有一個或多個任務(wù)。

2) 一個線程是進(jìn)程任務(wù)的一種機(jī)制，并且被用來計劃處理器的時間。

當(dāng)一個線程處于等待一個操作（例如讀寫磁盤）完成的空閑期時，Windows 2000操作系統(tǒng)通過轉(zhuǎn)換線程來最大化處理器的使用。線程間的轉(zhuǎn)換叫做context switching.?每個SQL Server的實例用戶連接的一個線程池,池中的線程被叫做工作線程。

當(dāng)Processor: %Processor Time?持續(xù)接近100%并且System: Processor Queue Length?顯示更多的應(yīng)用的進(jìn)程正在等待處理器，或者當(dāng)System: Context Switches/Sec?較高。顯示出現(xiàn)了系統(tǒng)瓶頸。當(dāng)Processor:% Processor Time?接近100%并且System: Context Switches/Sec?接近8000，考慮更快的處理器，附加的處理器或者轉(zhuǎn)換到使用纖程。

請觀察以下與內(nèi)存有關(guān)的計數(shù)器,以便及時發(fā)現(xiàn)和解決處理器上的問題。

使用工具：Windows?性能監(jiān)視器

對象:?計數(shù)器

描述

指導(dǎo)

Processor: %Processor Time

以處理器運行非空閑線程所經(jīng)歷時間的百分比表示。它被視為用于處理有效工作的時間比。每一個處理器在空閑時將會指定一個空閑線程來消耗未被其他線程使用的處理器時間段。

這個計數(shù)器應(yīng)該低于90%，如果這個計數(shù)器較高，應(yīng)降低工作負(fù)荷，提高工作效率或者或加大處理器的能力。

System: Context Switches/sec

監(jiān)控處理器每秒在線程間轉(zhuǎn)換的次數(shù)。

在一個多處理器的計算機(jī)上,如果這個計數(shù)器達(dá)到8000,并且Processor:% Processor Time計數(shù)器超過90%,考慮使用SQL Server fiber scheduling.

System: Processor Queue Length

監(jiān)控等待進(jìn)程時間的線程的數(shù)目

這個計數(shù)器不應(yīng)該持續(xù)大于2。如果這個計數(shù)器持續(xù)大于2，降低工作負(fù)荷,提高工作負(fù)荷的效率，或者增加處理器的能力，在多處理器的系統(tǒng)中可以增加處理器。

Processor: % Privileged Time

在“特權(quán)模式”下處理器運行非空閑線程所經(jīng)歷時間的百分比。Windows NT服務(wù)層，執(zhí)行體子程序及Windows NT內(nèi)核都是在“特權(quán)方式”下運行。

如果處理器的大部分時間被用來做系統(tǒng)內(nèi)核命令,并且物理硬盤的計數(shù)器較高，考慮提高硬盤輸入輸出子系統(tǒng)的性能。

Processor: %User Time

在“用戶模式”下處理器運行非空閑線程所經(jīng)歷時間的百分比。所有應(yīng)用程序碼及子系統(tǒng)碼都在“用戶模式“下運行。

這個能確定其它進(jìn)程或應(yīng)用正在執(zhí)行或阻止SQL Server操作。

2.3 監(jiān)控硬盤輸入輸出

SQL Server 使用Windows 2000 I/O calls 執(zhí)行磁盤的讀寫。SQL Server管理何時和如何執(zhí)行磁盤讀寫，但依賴Windows執(zhí)行底層的輸入輸出操作。I/O子系統(tǒng)包括系統(tǒng)總線，磁盤控制卡，磁盤，磁帶驅(qū)動器，CD-ROM驅(qū)動器和許多其它的I/O設(shè)備。磁盤經(jīng)常是系統(tǒng)的最大的瓶頸。

監(jiān)控硬盤輸入輸出將幫助你確定讀頁和寫頁是否超出硬盤子系統(tǒng)的能力。一個忙碌的硬盤子系統(tǒng)也可以顯示不足的內(nèi)存所引起的過多的頁面調(diào)度輸入輸出。

下面的表描述了優(yōu)化對象計數(shù)器，你可以用來監(jiān)控你的硬盤子系統(tǒng)的性能。

使用工具:Windows?性能監(jiān)視器

對象：計數(shù)器

描述

指導(dǎo)

PhysicalDisk: %Disk Time

所選的驅(qū)動器忙于處理讀取或?qū)懭胝埱笞鞣?wù)所花費時間的百分比。

這個計數(shù)器應(yīng)當(dāng)持續(xù)低于90%。

推薦值：小于50%

PhysicalDisk:Avg.Disk Queue Length

指在采樣間隔期內(nèi)，對所選磁盤的讀寫操作被排入隊列的平均次數(shù)。

這個計數(shù)器應(yīng)該不超過中心值的兩倍。

PhysicalDisk:Disk Read/sec

讀取磁盤的速度

這個計數(shù)器應(yīng)該續(xù)低于硬盤子系統(tǒng)的能力。

PhysicalDisk: Disk Writes/sec

寫入磁盤的速度

這個計數(shù)器應(yīng)持續(xù)低于硬盤子系統(tǒng)的能力。

如果這些硬盤計數(shù)器顯示你的硬盤正在超負(fù)荷運行，考慮：

1. 通過使用一個更快的硬盤，提高硬盤輸入輸出能力

2. 把一些文件轉(zhuǎn)移到一個附加硬盤或服務(wù)器上

3. 增加一個硬盤陣列

4. 提高硬盤的數(shù)量有助于減少硬盤的壓力。

SQL SERVER中一些常見性能問題的總結(jié)

1.對查詢進(jìn)行優(yōu)化，應(yīng)盡量避免全表掃描，首先應(yīng)考慮在 where 及 order by 涉及的列上建立索引。

2.應(yīng)盡量避免在 where 子句中對字段進(jìn)行 null 值判斷，否則將導(dǎo)致引擎放棄使用索引而進(jìn)行全表掃描，如：

select id from t where num is null

可以在num上設(shè)置默認(rèn)值0，確保表中num列沒有null值，然后這樣查詢：

select id from t where num=0

3.應(yīng)盡量避免在 where 子句中使用!=或<>操作符，否則將引擎放棄使用索引而進(jìn)行全表掃描。

4.應(yīng)盡量避免在 where 子句中使用 or 來連接條件，否則將導(dǎo)致引擎放棄使用索引而進(jìn)行全表掃描，如：

select id from t where num=10 or num=20

可以這樣查詢：

select id from t where num=10

union all

select id from t where num=20

5.in 和 not in 也要慎用，否則會導(dǎo)致全表掃描，如：

select id from t where num in(1,2,3)

對于連續(xù)的數(shù)值，能用 between 就不要用 in 了：

select id from t where num between 1 and 3

6.下面的查詢也將導(dǎo)致全表掃描：

select id from t where name like '%abc%'

若要提高效率，可以考慮全文檢索。

7.如果在 where 子句中使用參數(shù)，也會導(dǎo)致全表掃描。因為SQL只有在運行時才會解析局部變量，但優(yōu)化程序不能將訪問計劃的選擇推遲到運

行時；它必須在編譯時進(jìn)行選擇。然而，如果在編譯時建立訪問計劃，變量的值還是未知的，因而無法作為索引選擇的輸入項。如下面語句將

進(jìn)行全表掃描：

select id from t where num=@num

可以改為強(qiáng)制查詢使用索引：

select id from t with(index(索引名)) where num=@num

8.應(yīng)盡量避免在 where 子句中對字段進(jìn)行表達(dá)式操作，這將導(dǎo)致引擎放棄使用索引而進(jìn)行全表掃描。如：

select id from t where num/2=100

應(yīng)改為:

select id from t where num=100*2

9.應(yīng)盡量避免在where子句中對字段進(jìn)行函數(shù)操作，這將導(dǎo)致引擎放棄使用索引而進(jìn)行全表掃描。如：

select id from t where substring(name,1,3)='abc'--name以abc開頭的id

select id from t where datediff(day,createdate,'2005-11-30')=0--‘2005-11-30’生成的id

應(yīng)改為:

select id from t where name like 'abc%'

select id from t where createdate>='2005-11-30' and createdate<'2005-12-1'

10.不要在 where 子句中的“=”左邊進(jìn)行函數(shù)、算術(shù)運算或其他表達(dá)式運算，否則系統(tǒng)將可能無法正確使用索引。

11.在使用索引字段作為條件時，如果該索引是復(fù)合索引，那么必須使用到該索引中的第一個字段作為條件時才能保證系統(tǒng)使用該索引，否則該索引將不會被使用，并且應(yīng)盡可能的讓字段順序與索引順序相一致。

12.不要寫一些沒有意義的查詢，如需要生成一個空表結(jié)構(gòu)：

select col1,col2 into #t from t where 1=0

這類代碼不會返回任何結(jié)果集，但是會消耗系統(tǒng)資源的，應(yīng)改成這樣：

create table #t(...)

13.很多時候用 exists 代替 in 是一個好的選擇：

select num from a where num in(select num from b)

用下面的語句替換：

select num from a where exists(select 1 from b where num=a.num)

14.并不是所有索引對查詢都有效，SQL是根據(jù)表中數(shù)據(jù)來進(jìn)行查詢優(yōu)化的，當(dāng)索引列有大量數(shù)據(jù)重復(fù)時，SQL查詢可能不會去利用索引，如一表中有字段sex，male、female幾乎各一半，那么即使在sex上建了索引也對查詢效率起不了作用。

15.索引并不是越多越好，索引固然可以提高相應(yīng)的 select 的效率，但同時也降低了 insert 及 update 的效率，因為 insert 或 update 時有可能會重建索引，所以怎樣建索引需要慎重考慮，視具體情況而定。一個表的索引數(shù)最好不要超過6個，若太多則應(yīng)考慮一些不常使用到的列上建的索引是否有必要。

16.應(yīng)盡可能的避免更新 clustered 索引數(shù)據(jù)列，因為 clustered 索引數(shù)據(jù)列的順序就是表記錄的物理存儲順序，一旦該列值改變將導(dǎo)致整個表記錄的順序的調(diào)整，會耗費相當(dāng)大的資源。若應(yīng)用系統(tǒng)需要頻繁更新 clustered 索引數(shù)據(jù)列，那么需要考慮是否應(yīng)將該索引建為 clustered 索引。

17.盡量使用數(shù)字型字段，若只含數(shù)值信息的字段盡量不要設(shè)計為字符型，這會降低查詢和連接的性能，并會增加存儲開銷。這是因為引擎在處理查詢和連接時會逐個比較字符串中每一個字符，而對于數(shù)字型而言只需要比較一次就夠了。

18.盡可能的使用 varchar/nvarchar 代替 char/nchar ，因為首先變長字段存儲空間小，可以節(jié)省存儲空間，其次對于查詢來說，在一個相對較小的字段內(nèi)搜索效率顯然要高些。

19.任何地方都不要使用 select * from t ，用具體的字段列表代替“*”，不要返回用不到的任何字段。

20.盡量使用表變量來代替臨時表。如果表變量包含大量數(shù)據(jù)，請注意索引非常有限（只有主鍵索引）。

21.避免頻繁創(chuàng)建和刪除臨時表，以減少系統(tǒng)表資源的消耗。

22.臨時表并不是不可使用，適當(dāng)?shù)厥褂盟鼈兛梢允鼓承├谈行?#xff0c;例如，當(dāng)需要重復(fù)引用大型表或常用表中的某個數(shù)據(jù)集時。但是，對于一次性事件，最好使用導(dǎo)出表。

23.在新建臨時表時，如果一次性插入數(shù)據(jù)量很大，那么可以使用 select into 代替 create table，避免造成大量 log ，以提高速度；如果數(shù)據(jù)量不大，為了緩和系統(tǒng)表的資源，應(yīng)先create table，然后insert。

24.如果使用到了臨時表，在存儲過程的最后務(wù)必將所有的臨時表顯式刪除，先 truncate table ，然后 drop table ，這樣可以避免系統(tǒng)表的較長時間鎖定。

25.盡量避免使用游標(biāo)，因為游標(biāo)的效率較差，如果游標(biāo)操作的數(shù)據(jù)超過1萬行，那么就應(yīng)該考慮改寫。

26.使用基于游標(biāo)的方法或臨時表方法之前，應(yīng)先尋找基于集的解決方案來解決問題，基于集的方法通常更有效。

27.與臨時表一樣，游標(biāo)并不是不可使用。對小型數(shù)據(jù)集使用 FAST_FORWARD 游標(biāo)通常要優(yōu)于其他逐行處理方法，尤其是在必須引用幾個表才能獲得所需的數(shù)據(jù)時。在結(jié)果集中包括“合計”的例程通常要比使用游標(biāo)執(zhí)行的速度快。如果開發(fā)時間允許，基于游標(biāo)的方法和基于集的方法都可以嘗試一下，看哪一種方法的效果更好。

28.在所有的存儲過程和觸發(fā)器的開始處設(shè)置 SET NOCOUNT ON ，在結(jié)束時設(shè)置 SET NOCOUNT OFF 。無需在執(zhí)行存儲過程和觸發(fā)器的每個語句后向客戶端發(fā)送 DONE_IN_PROC 消息。

29.盡量避免大事務(wù)操作，提高系統(tǒng)并發(fā)能力。

30.盡量避免向客戶端返回大數(shù)據(jù)量，若數(shù)據(jù)量過大，應(yīng)該考慮相應(yīng)需求是否合理。

具體的SQL語句在很多情況下需要結(jié)合實際的應(yīng)用情況來寫，這里不作敘述。

--Windows 2003支持4G內(nèi)存

[boot loader]

timeout=30

default=multi(0)disk(0)rdisk(0)partition(2)/WINDOWS

[operating systems]

multi(0)disk(0)rdisk(0)partition(2)/WINDOWS="Windows Server 2003, Standard" /fastdetect /3GB

將Boot.ini文件加好參數(shù):

/fastdetect /3GB

對數(shù)據(jù)庫中一些數(shù)據(jù)量較大的表（如T_Voucher,T_VoucherEntry,T_Balance,

IcStockBill,IcStockBillEntry等）可以在SQL SERVER中制作一個作業(yè)在系統(tǒng)空閑時定時進(jìn)行重建索引，例如“dbcc dbreindex('icstockbill')；dbcc dbreindex('icstockbillEntry')”2個sql進(jìn)行出入庫單據(jù)表的專門索引優(yōu)化。

轉(zhuǎn)載于:https://blog.51cto.com/211721/1845479

總結(jié)

以上是生活随笔為你收集整理的K3数据库优化方案的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。