【文章內(nèi)容簡(jiǎn)介】 數(shù)據(jù)的媒體與各數(shù)據(jù)塊的對(duì)應(yīng)關(guān)系。多個(gè)數(shù)據(jù)表可以共用相同的數(shù)據(jù)分區(qū)函數(shù)，一般不共用相同的數(shù)據(jù)分區(qū)方案?？梢酝ㄟ^(guò)不同的分區(qū)方案，使用相同的分區(qū)函數(shù)，使不同的數(shù)據(jù)表有相同的分區(qū)條件，但存放在不同的媒介上。創(chuàng)建分區(qū)方案的代碼如下： CREATE PARTITION SCHEME[SendSMSPS] AS PARTITION[SendSMSPF] TO ([FG1]，[FG2]，[FG3]，[FG4]) 建立好分區(qū)函數(shù)和分區(qū)方案后，就可以創(chuàng)建分區(qū)表了。分區(qū)表是通過(guò)定義分區(qū)鍵值和分區(qū)方案相聯(lián)系的。插入記錄時(shí)，SQL SERVER會(huì)根據(jù)分區(qū)鍵值的不同，通過(guò)分區(qū)函數(shù)的定義將數(shù)據(jù)放到相應(yīng)的分區(qū)。從而把分區(qū)函數(shù)、分區(qū)方案和分區(qū)表三者有機(jī)的結(jié)合起來(lái)。創(chuàng)建分區(qū)表的代碼如下： CREATE TABLE SendSMSLog([ID][int]IDENTITY(1，1)NOT NULL，[IDNum][nvarchar](50)NULL，[SendContent][text]NULL[SendDate][datetime]NOTNULL，)ON SendSMSPS(SendDate) 系統(tǒng)運(yùn)行一段時(shí)間或者把以前的數(shù)據(jù)導(dǎo)入分區(qū)表后，我們需要查看數(shù)據(jù)的具體存儲(chǔ)情況，即每個(gè)分區(qū)存取的記錄數(shù)，那些記錄存取在那個(gè)分區(qū)等。我們可以通過(guò)$，代碼如下： SELECT$()AS[Partition Number]，min()AS[Min SendDate]，max()AS[Max SendDate]，count(*)AS[Rows In Partition]FROM AS oGROUP BY$()ORDER BY[Partition Number] 分區(qū)的維護(hù)主要設(shè)計(jì)分區(qū)的添加、減少、合并和在分區(qū)間轉(zhuǎn)換?？梢酝ㄟ^(guò)ALTER PARTITION FUNCTION的選項(xiàng)SPLIT，MERGE和ALTER TABLE的選項(xiàng)SWITCH來(lái)實(shí)現(xiàn)。SPLIT會(huì)多增加一個(gè)分區(qū)，而MEGRE會(huì)合并或者減少分區(qū)，SWITCH則是邏輯地在組間轉(zhuǎn)換分區(qū)。 SQL查詢語(yǔ)句的優(yōu)化 數(shù)據(jù)庫(kù)的優(yōu)化通?？梢酝ㄟ^(guò)對(duì)網(wǎng)絡(luò)、硬件、操作系統(tǒng)、數(shù)據(jù)庫(kù)參數(shù)和應(yīng)用程序的優(yōu)化來(lái)進(jìn)行。最常見(jiàn)的優(yōu)化手段就是對(duì)硬件的升級(jí)。根據(jù)統(tǒng)計(jì)，對(duì)網(wǎng)絡(luò)、硬件、操作系統(tǒng)、數(shù)據(jù)庫(kù)參數(shù)進(jìn)行優(yōu)化所獲得的性能提升，全部加起來(lái)只占數(shù)據(jù)庫(kù)系統(tǒng)性能提升的40%左右，其余的60%系統(tǒng)性能提升來(lái)自對(duì)應(yīng)用程序的優(yōu)化。許多優(yōu)化專家認(rèn)為，對(duì)應(yīng)用程序的優(yōu)化可以得到80%的系統(tǒng)性能的提升。應(yīng)用程序的優(yōu)化通?？煞譃閮蓚€(gè)方面：源代碼和SQL語(yǔ)句。由于涉及到對(duì)程序邏輯的改變，源代碼的優(yōu)化在時(shí)間成本和風(fēng)險(xiǎn)上代價(jià)很高，而對(duì)數(shù)據(jù)庫(kù)系統(tǒng)性能的提升收效有限。所以SQL語(yǔ)句的優(yōu)化對(duì)數(shù)據(jù)庫(kù)系統(tǒng)的性能起著決定性的作用。 SQL語(yǔ)言是一種靈活的語(yǔ)言，相同的功能可以使用不同的語(yǔ)句來(lái)實(shí)現(xiàn)，但是語(yǔ)句的執(zhí)行效率是很不相同的。程序員可以通過(guò)查看查詢計(jì)劃來(lái)比較各種實(shí)現(xiàn)方案，并選出最優(yōu)的實(shí)現(xiàn)方案?？偟脕?lái)講，程序員寫(xiě)SQL語(yǔ)句需要滿足考慮如下規(guī)則： 索引是一種供服務(wù)器在表中快速查找一個(gè)行的數(shù)據(jù)庫(kù)結(jié)構(gòu)。 在關(guān)系數(shù)據(jù)庫(kù)中，一個(gè)行的物理位置無(wú)關(guān)緊要，除非數(shù)據(jù)庫(kù)需要找到它。為了能找到數(shù)據(jù)。表中的每一行均用一個(gè)ROWID來(lái)標(biāo)識(shí)，ROWID告訴數(shù)據(jù)庫(kù)這一行的準(zhǔn)確位置(指出行所在的文件、該文件中的塊、該塊中的行地址)。每一個(gè)索引條目都由一個(gè)鍵值和ROWID組成?？梢运饕粋€(gè)列或一組列，SQL SERVER用B樹(shù)結(jié)構(gòu)存儲(chǔ)索引條目，以保證用最短路徑訪問(wèn)鍵值，當(dāng)一個(gè)查詢?cè)L問(wèn)索引時(shí)，就能找到與查詢條件相匹配的索引條目。與條目相匹配的ROWID值指向SQL SERVER提供相關(guān)行的物理位置，以減輕定位數(shù)據(jù)所需要的I/O負(fù)擔(dān)。 從大多數(shù)系統(tǒng)應(yīng)用實(shí)例來(lái)看，查詢操作在各種數(shù)據(jù)庫(kù)的操作中，所占的比重最大。索引是數(shù)據(jù)庫(kù)的重要的數(shù)據(jù)結(jié)構(gòu),它的根本目的就是為了提高查詢速度。實(shí)踐證明在數(shù)據(jù)庫(kù)編程中，合理使用索引文件，對(duì)于改善數(shù)據(jù)查詢速度有著舉足輕重的作用，可以極大改善數(shù)據(jù)庫(kù)應(yīng)用程序的性能。 在應(yīng)用過(guò)程中，用戶的查詢條件可能是多種多樣的，如果能根據(jù)用戶查詢建立和選擇索引，對(duì)于保證應(yīng)用程序的性能很有幫助。 ，一般使用的原則為： (1)為主鍵所在的列創(chuàng)建索引。為經(jīng)常進(jìn)行連接，但是沒(méi)有指定為外鍵的字段建立索引，而不經(jīng)常連接的字段由數(shù)據(jù)庫(kù)優(yōu)化器自動(dòng)建立索引。 (2)在頻繁進(jìn)行排序或分組(即使用GROUP BY或ORDER BY操作)的字段上建立索引。 (3)在條件表達(dá)式中經(jīng)常用到的不同值較多的字段上建立索引，在不同值較少的字段上不要建立索引，如性別字段就不需要建立索引。不要在在查詢很少引用的列上創(chuàng)建索引。 (4)如果經(jīng)常同時(shí)使用多個(gè)字段排序，可以在這些字段上建立復(fù)合索引。要盡量使關(guān)鍵查詢形成索引覆蓋，其前導(dǎo)字段一定是使用最頻繁的字段。 (5)查看索引并刪除不使用的索引，維護(hù)索引需要一定的硬盤(pán)空間和時(shí)間，需要頻繁進(jìn)行數(shù)據(jù)查入操作的數(shù)據(jù)庫(kù)應(yīng)該有較少的索引，需要頻繁進(jìn)行讀取操作的數(shù)據(jù)庫(kù)應(yīng)該有更多的索引。 (6)在聚集索引中，避免包括不必要的列，盡可能使用較小的數(shù)據(jù)類型，例如用VARCHAR代替CHAR。 (7)考慮使用聚集索引來(lái)支持排序和范圍查詢，在為數(shù)據(jù)檢索而優(yōu)化表的時(shí)候，聚集索引應(yīng)該支持對(duì)記錄組的檢索。為了聚集鍵選擇列或列組，其中聚集鍵根據(jù)需要經(jīng)常排序的排序數(shù)據(jù)或?qū)Ρ仨氁黄鹪L問(wèn)的記錄進(jìn)行分組。 (8)具有高選擇性的列是索引的好候選列，具有高密度的列是索引最糟糕的候選列。 在創(chuàng)建索引后，必須維護(hù)索引以確?？梢垣@得最佳的性能。經(jīng)過(guò)一段時(shí)間后，數(shù)據(jù)會(huì)變得支離破碎，要根據(jù)組織環(huán)境對(duì)數(shù)據(jù)碎片進(jìn)行整理。 SQL Server 2000索引優(yōu)化向?qū)且粋€(gè)你會(huì)馬上喜歡上的工具。雖然并不完美，但是這個(gè)工具可以評(píng)估查詢運(yùn)行性能，并基于查詢，提出數(shù)據(jù)表上是否該添加聚集/非聚集索引的建議。索引優(yōu)化向?qū)г赟QL Server 2000事件探查器的“工具”菜單下可以找到。 使用索引優(yōu)化向?qū)?，首先要?jiǎng)?chuàng)建工作負(fù)載。工作負(fù)載表示一個(gè)事件跟蹤或者TSQL腳本。在很多情況下，你應(yīng)該選擇使用事件跟蹤，因?yàn)樗磻?yīng)了真實(shí)的數(shù)據(jù)庫(kù)行為。工作負(fù)載的創(chuàng)建必須能體現(xiàn)一段時(shí)間內(nèi)每天數(shù)據(jù)庫(kù)使用的情況。這樣，索引優(yōu)化向?qū)Ь涂梢曰谶@些實(shí)際運(yùn)行的統(tǒng)計(jì)行為來(lái)提出有用的建議。當(dāng)工作負(fù)載創(chuàng)建后，索引優(yōu)化向?qū)Ь秃芨櫵?。索引?yōu)化向?qū)龅木褪菑墓ぷ髫?fù)載中提取行為樣本，然后利用查詢優(yōu)化器進(jìn)行分析。 一旦索引優(yōu)化向?qū)Х治鐾旯ぷ髫?fù)載后(如果工作負(fù)載很大，這會(huì)運(yùn)行幾個(gè)小時(shí)那么長(zhǎng))，基于對(duì)工作負(fù)載的分析，提出最佳的聚集/非聚集索引建議。另外，如果數(shù)據(jù)庫(kù)上已經(jīng)有索引了，并且索引優(yōu)化向?qū)Оl(fā)現(xiàn)這些索引不是最佳的，那么會(huì)建議你移除。 3在數(shù)據(jù)庫(kù)中放置索引 用戶可以指定一個(gè)表的索引放置的位置。一個(gè)表的索引就該放置在與數(shù)據(jù)表不同的物理磁盤(pán)上，這樣可以減少文件之間的磁盤(pán)爭(zhēng)用。 ，保證在實(shí)現(xiàn)功能的基礎(chǔ)上，盡量減少對(duì)數(shù)據(jù)庫(kù)的訪問(wèn)次數(shù)；通過(guò)搜索參數(shù)，盡量減少對(duì)表的訪問(wèn)行數(shù)，最小化結(jié)果集，從而減輕網(wǎng)絡(luò)負(fù)擔(dān)；能夠分開(kāi)的操作盡量分開(kāi)處理，提高每次的響應(yīng)速度；在數(shù)據(jù)窗口使用SQL時(shí)，盡量把使用的索引放在選擇的首列。 ；在查詢時(shí)，不要過(guò)多地使用通配符如SELECT * FROM T1語(yǔ)句，要用到幾列就選擇幾列，如：SELECT COL1，COL2 FROM T1；在可能的情況下盡量限制結(jié)果集行數(shù)，如：SELECT TOP 300 COL1，COL2，COL3 FROM T1，因?yàn)槟承┣闆r下用戶是不需要那么多的數(shù)據(jù)的。不要在應(yīng)用中使用數(shù)據(jù)庫(kù)游標(biāo)，游標(biāo)是非常有用的工具，但比使用常規(guī)的、面向集的SQL語(yǔ)句需要更大的開(kāi)銷；按照特定順序提取數(shù)據(jù)的查找。 。例如float和int、char和varchar、binary和varbinary是不兼容的。數(shù)據(jù)類型的不兼容可能使優(yōu)化器無(wú)法執(zhí)行一些本來(lái)可以進(jìn)行的優(yōu)化操作。例如： SELECT name FROM employee WHERE salary＞60000在這條語(yǔ)句中，如salary字段是money型的，則優(yōu)化器很難對(duì)其進(jìn)行優(yōu)化，因?yàn)?0000是個(gè)整型數(shù)。我們應(yīng)當(dāng)在編程時(shí)將整型轉(zhuǎn)化成為貨幣型，而不要等到運(yùn)行時(shí)轉(zhuǎn)化。 ，這將導(dǎo)致引擎放棄使用索引而進(jìn)行全表掃描。如： (1)SELECT * FROM T1 WHERE F1/2=100 應(yīng)改為: SELECT * FROM T1 WHERE F1=100*2 (2)SELECT * FROM RECORD WHERE SUBSTRING(CARD_NO，1，4)=’5378’ 應(yīng)改為： SELECT * FROM RECORD WHERE CARD_NO LIKE‘5378%’ (3)SELECT member_number，first_name，last_name FROM members WHEREDATEDIFF(yy，datofbirth，GETDATE())21 應(yīng)改為： SELECT member_number，first_name，last_name FROM members WHEREdateofbirthDATEADD(yy，21，GETDATE()) 即：任何對(duì)列的操作都將導(dǎo)致表掃描，它包括數(shù)據(jù)庫(kù)函數(shù)、計(jì)算表達(dá)式等等，查詢時(shí)要盡可能將操作移至等號(hào)右邊。 !=或＜＞、IS NULL或IS NOT NULL、IN，NOT IN等這樣的操作符，因?yàn)檫@會(huì)使系統(tǒng)無(wú)法使用索引，而只能直接搜索表中的數(shù)據(jù)。例如: SELECT id FROM employee WHERE id!=39。B%39。 優(yōu)化器將無(wú)法通過(guò)索引來(lái)確定將要命中的行數(shù)，因此需要搜索該表的所有行。 ，一部分開(kāi)發(fā)人員和數(shù)據(jù)庫(kù)管理人員喜歡把包含數(shù)值信息的字段設(shè)計(jì)為字符型，這會(huì)降低查詢和連接的性能，并會(huì)增加存儲(chǔ)開(kāi)銷。這是因?yàn)橐嬖谔幚聿樵兒瓦B接回逐個(gè)比較字符串中每一個(gè)字符，而對(duì)于數(shù)字型而言只需要比較一次就夠了。 、NOT EXISTS子句。如下所示： (1).SELECT SUM()FROM T1 WHERE(SELECT COUNT(*)FROMT2 WHERE =)0 (2).SELECT SUM()FROM T1 WHERE EXISTS(SELECT*FROM T2WHERE =) 兩者產(chǎn)生相同的結(jié)果，但是后者的效率顯然要高于前者。因?yàn)楹笳卟粫?huì)產(chǎn)生大量鎖定的表掃描或是索引掃描。 ，不要用count(*)那樣效率很低，而且浪費(fèi)服務(wù)器資源?？梢杂肊XISTS代替。如： IF(SELECT COUNT(*)FROM table_name WHERE column_name=39。xxx39。)0 可以寫(xiě)成：IF EXISTS(SELECT*FROM table_name WHERE column_name=39。xxx39。) ，從而找到是否存在在父結(jié)果集中有而在子結(jié)果集中沒(méi)有的記錄，如： (1).SELECT FROM HDR_TBL A WHERE NOT EXISTS(SELECT * FROM DTL_TBL B WHERE =) (2).SELECT FROM HDR_TBL A LEFT JOIN DTL_DTL BON = WHERE IS NULL (3).SELECT HDR_KEY FROM HDR_TBL WHERE HDR_KEY NOT IN(SELECT HDR_KEY FROM DTL_TBL) 三種寫(xiě)法都可以得到同樣正確的結(jié)果，但是效率依次降低。