SQL優(yōu)化的幾個(gè)方面.doc

1、SQL 優(yōu)化的幾個(gè)方面sql 數(shù)據(jù)庫(kù)優(yōu)化非常重要，如果sql 數(shù)據(jù)庫(kù)優(yōu)化的不好，不僅會(huì)增加客戶(hù)端和服務(wù)器端程序的編程和維護(hù)的難度，而且還會(huì)影響系統(tǒng)實(shí)際運(yùn)行的性能。那我們可以從哪些方面來(lái)進(jìn)行sql 數(shù)據(jù)庫(kù)優(yōu)化呢？一：就是合理的數(shù)據(jù)庫(kù)的設(shè)計(jì)。當(dāng)前我們使用最多的就是關(guān)系型數(shù)據(jù)庫(kù)，關(guān)系數(shù)據(jù)庫(kù)設(shè)計(jì)是對(duì)數(shù)據(jù)進(jìn)行組織化和結(jié)構(gòu)化的過(guò)程，核心問(wèn)題是關(guān)系模型的設(shè)計(jì)。對(duì)于數(shù)據(jù)庫(kù)規(guī)模較小的情況，我們可以比較輕松的處理數(shù)據(jù)庫(kù)中的表結(jié)構(gòu)。然而，隨著項(xiàng)目規(guī)模的不斷增長(zhǎng)，相應(yīng)的數(shù)據(jù)庫(kù)也變得更加復(fù)雜，關(guān)系模型表結(jié)構(gòu)更為龐雜，這時(shí)我們往往會(huì)發(fā)現(xiàn)我們寫(xiě)出來(lái)的 SQL 語(yǔ)句的是很笨拙并且效率低下的。更糟糕的是，由于表結(jié)構(gòu)定義的不合理

2、，會(huì)導(dǎo)致在更新數(shù)據(jù)時(shí)造成數(shù)據(jù)的不完整。因此數(shù)據(jù)庫(kù)的規(guī)范化流程尤為重要，它可以以指導(dǎo)我們更好的設(shè)計(jì)數(shù)據(jù)庫(kù)的表結(jié)構(gòu)，減少冗余的數(shù)據(jù)，借此可以提高數(shù)據(jù)庫(kù)的存儲(chǔ)效率，數(shù)據(jù)完整性和可擴(kuò)展性。那怎么才算是規(guī)范化的設(shè)計(jì)流程：規(guī)范化設(shè)計(jì)的過(guò)程就是按不同的范式，將一個(gè)二維表不斷地分解成多個(gè)二維表并建立表之間的關(guān)聯(lián)，最終達(dá)到一個(gè)表只描述一個(gè)實(shí)體或者實(shí)體間的一種聯(lián)系的目標(biāo)。目前遵循的主要范式包括1NF 、 2 NF 、3 NF 、 BCNF 、4NF 和 5NF 等幾種；在工程中3NF、 BCNF 應(yīng)用得最廣泛，推薦采用3NF 作為標(biāo)準(zhǔn)。規(guī)范化設(shè)計(jì)的優(yōu)點(diǎn)包括可有效地消除數(shù)據(jù)冗余，理順數(shù)據(jù)的從屬關(guān)系，保持?jǐn)?shù)據(jù)庫(kù)的完整

3、性，增強(qiáng)數(shù)據(jù)庫(kù)的穩(wěn)定性、伸縮性、適應(yīng)性。通常認(rèn)為規(guī)范化設(shè)計(jì)存在的主要問(wèn)題是增加了查詢(xún)時(shí)的連接庫(kù)表運(yùn)算，導(dǎo)致計(jì)算機(jī)時(shí)間、空間、系統(tǒng)及運(yùn)行效率的損失。在大多數(shù)情況下，這一問(wèn)題可通過(guò)良好的索引設(shè)計(jì)等方法得到解決。數(shù)據(jù)庫(kù)設(shè)計(jì)中關(guān)鍵的步驟就是要確保數(shù)據(jù)正確地分布到數(shù)據(jù)庫(kù)的表中。比如說(shuō)，一個(gè)客戶(hù)的地址信息不應(yīng)該被存儲(chǔ)在不同的表中，因?yàn)檫@里的客戶(hù)地址是雇員的一個(gè)屬性。如果存在過(guò)多的冗余數(shù)據(jù)，這就意味著要占用了更多的物理空間，同時(shí)也對(duì)數(shù)據(jù)的維護(hù)和一致性檢查帶來(lái)了問(wèn)題，當(dāng)這個(gè)客戶(hù)的地址發(fā)生變化時(shí)，冗余數(shù)據(jù)會(huì)導(dǎo)致對(duì)多個(gè)表的更新動(dòng)作，如果有一個(gè)表不幸被忽略了，那么就可能導(dǎo)致數(shù)據(jù)的不一致性。二：查詢(xún)的優(yōu)化如何讓你寫(xiě)的

4、 SQL 語(yǔ)句跑的更快呢？影響我們代碼速度的都有哪些可能性呢？不恰當(dāng)?shù)乃饕O(shè)計(jì)、不充份的連接條件和不可優(yōu)化的 where 子句都有可能造成速度的下降。首先來(lái)看看索引的建立。微軟的sqlserver提供了兩種索引：聚集索引（clustered index，也稱(chēng)聚類(lèi)索引、簇集索引）和非聚集索引（nonclusteredindex，也稱(chēng)非聚類(lèi)索引、非簇集索引），聚集索引簡(jiǎn)單理解就是數(shù)據(jù)的實(shí)際的存放位置：如我們的漢語(yǔ)字典正文本身就是一個(gè)聚集索引，當(dāng)我們知道要查的字拼音首字母為 A 時(shí)，迅速縮小查詢(xún)范圍，翻到前幾頁(yè)就可以很快找到了，避免全表掃描，當(dāng)然這種索引對(duì)于一個(gè)表只能有一個(gè)，因?yàn)橹荒馨凑找环N方法進(jìn)行

5、排序存放，所以一定得選擇最合適的聚集索引規(guī)則。非聚集索引，簡(jiǎn)單來(lái)說(shuō)就是目錄，比如字典中的偏旁部首目錄，當(dāng)我們要查找數(shù)據(jù)的時(shí)候我們先通過(guò)目錄縮寫(xiě)范圍，再進(jìn)行查詢(xún)目標(biāo)的確認(rèn)。下表我們可以作為參考建立適合的索引索引有助于提高檢索性能，但過(guò)多或不當(dāng)?shù)乃饕矔?huì)導(dǎo)致系統(tǒng)低效。因?yàn)橛脩?hù)在表中每加進(jìn)一個(gè)索引，數(shù)據(jù)庫(kù)就要做更多的工作。過(guò)多的索引甚至?xí)?dǎo)致索引碎片。所以合適的索引才能使數(shù)據(jù)庫(kù)得到性能的提高。再者就是連接條件：其實(shí)在多表鏈接操作被實(shí)際執(zhí)行前，查詢(xún)優(yōu)化器會(huì)根據(jù)連接條件，列出幾組可能的連接方案并從中找出系統(tǒng)開(kāi)銷(xiāo)最小的最佳方案。連接條件要充份考慮帶有索引的表、數(shù)據(jù)記錄數(shù)多的表；可以打開(kāi)執(zhí)行計(jì)劃，看具體的執(zhí)

6、行情況，哪些環(huán)節(jié)的資源的占用大，是否可以?xún)?yōu)化查詢(xún)或者優(yōu)化結(jié)構(gòu)。另外：動(dòng)態(tài)管理視圖 (DMV) 和動(dòng)態(tài)管理函數(shù)(DMF) 返回的服務(wù)器狀態(tài)信息可用于監(jiān)控服務(wù)器實(shí)例的運(yùn)行狀況、診斷問(wèn)題和優(yōu)化性能。如：查找哪些批處理/請(qǐng)求生成的I/O 最多、查詢(xún)以查看CPU 、計(jì)劃程序內(nèi)存和緩沖池信息、CPU平均占用率最高SQL語(yǔ)句等。涉及的視圖及函數(shù)如下：sys.dm_exec_sql_text、dm_exec_query_stats、 dm_os_sys_info 、dm_exec_cached_plans、 dm_exec_query_plan、等三：就是 where 條件我們建立了索引就不是就可以使查詢(xún)的速度達(dá)到最快，而是在查詢(xún)的時(shí)候要使用到索引，才會(huì)優(yōu)化我們的查詢(xún)速度。比例根據(jù)部門(mén)列建立了索引，但是我們?cè)谑褂貌块T(mén)的查詢(xún)條件的時(shí)候用 %XXX% ，此種條件是使用不到索引的，如下 like便可以 XXX% ;UNION 在進(jìn)行表鏈接后會(huì)篩選掉重復(fù)的記錄，而往往重復(fù)的基本上不存在，可以采用UNIONALL 操作符替代UNION ，因