如何做SqlServer 數(shù)據(jù)查詢優(yōu)化！

一、建立索引

成都一家集口碑和實(shí)力的網(wǎng)站建設(shè)服務(wù)商，擁有專業(yè)的企業(yè)建站團(tuán)隊(duì)和靠譜的建站技術(shù)，十多年企業(yè)及個(gè)人網(wǎng)站建設(shè)經(jīng)驗(yàn) ,為成都1000+客戶提供網(wǎng)頁(yè)設(shè)計(jì)制作,網(wǎng)站開(kāi)發(fā),企業(yè)網(wǎng)站制作建設(shè)等服務(wù),包括成都營(yíng)銷型網(wǎng)站建設(shè)，品牌網(wǎng)站制作，同時(shí)也為不同行業(yè)的客戶提供網(wǎng)站設(shè)計(jì)制作、成都網(wǎng)站建設(shè)的服務(wù),包括成都電商型網(wǎng)站制作建設(shè),裝修行業(yè)網(wǎng)站制作建設(shè)，傳統(tǒng)機(jī)械行業(yè)網(wǎng)站建設(shè),傳統(tǒng)農(nóng)業(yè)行業(yè)網(wǎng)站制作建設(shè)。在成都做網(wǎng)站,選網(wǎng)站制作建設(shè)服務(wù)商就選成都創(chuàng)新互聯(lián)。

二、建立存儲(chǔ)過(guò)程

三、只查詢您所需要的數(shù)據(jù)，不要把所有數(shù)據(jù)都查詢出來(lái)，防止數(shù)據(jù)冗余。

四、對(duì)于大量及海量數(shù)據(jù)一般還要建立分區(qū)

如何識(shí)別SQL Server中的CPU瓶頸

問(wèn)題：

如果經(jīng)常遇到CPU瓶頸而導(dǎo)致的SQLServer宕機(jī)，那如何去發(fā)現(xiàn)并解決這些相關(guān)的問(wèn)題？

解決方案：

導(dǎo)致CPU成為SQLServer性能問(wèn)題的原因有很多，比較明顯的原因是因?yàn)橘Y源不足。但是，CPU的利用率可以通過(guò)配置的更改和查詢的優(yōu)化來(lái)降低，所以當(dāng)你想買更快更好的處理器之前，先要考慮前面的操作。下面是使用一些內(nèi)置工具來(lái)識(shí)別CPU相關(guān)瓶頸：

性能監(jiān)視器（Performance Monitor）：

可以使用性能監(jiān)視器來(lái)檢查CPU的負(fù)載。檢查Processor:% Processor Time 這個(gè)計(jì)數(shù)器：如果長(zhǎng)期超過(guò)80%/處理器，那很有可能面臨了CPU相關(guān)瓶頸。

CPU密集操作主要是編譯和重編譯。你可以通過(guò)使用SQL Statistics對(duì)象計(jì)數(shù)器來(lái)監(jiān)視它們的情況。也可以監(jiān)控批處理接收的數(shù)量來(lái)查看。如果SQL Recompilations/sec 中的BatchRequests/sec的速率很高，那就有潛在的問(wèn)題：

配置和監(jiān)視以下計(jì)數(shù)器：

SQL Server: SQL Statistics: SQL Compilations/sec

SQL Server: SQL Statistics: SQL Recompilations/sec

SQL Server: SQL Statistics: Batch Requests/sec

可以從MSDN中獲取關(guān)于這部分的詳細(xì)信息： MSDN Library.

另外一個(gè)用于探測(cè)CPU相關(guān)問(wèn)題的計(jì)數(shù)器是：SQL Server: Cursor Manager By Type – CursorRequests/Sec ，用于顯示你的服務(wù)器上游標(biāo)使用情況。如果你看到每秒有數(shù)以百計(jì)的游標(biāo)請(qǐng)求，那很有可能是因?yàn)榈托У挠螛?biāo)使用和小體積提取操作（small fetch size）引起性能問(wèn)題。

內(nèi)部并行查詢同樣會(huì)引起CPU問(wèn)題，可以檢查：

SQL Statistics:Batch Requests/sec counter 計(jì)數(shù)器。在CPU生命周期中，每秒的批處理應(yīng)該很小。如果過(guò)多，意味著正在使用并行計(jì)劃運(yùn)行。

動(dòng)態(tài)管理視圖（DMVs）：

以下是對(duì)排查CPU瓶頸游泳的DMVs。動(dòng)態(tài)視圖：sys.dm_exec_query_stats顯示目前緩存的批處理或者使用CPU的過(guò)程。下面的查詢用于檢查耗費(fèi)CPU的執(zhí)行計(jì)劃：

select plan_handle,

sum(total_worker_time) as total_worker_time,

sum(execution_count) as total_execution_count,

count(*) as number_of_statements

from sys.dm_exec_query_stats

group by plan_handle

order bysum(total_worker_time), sum(execution_count) desc

SQLServer2008在每個(gè)查詢編譯時(shí)，會(huì)計(jì)算其hash值。你可以在query_hash列中找到該值，是否兩個(gè)查詢僅僅字面值不同但是使用相同query_hash值。該值也在 Showplan/Statistics XML QueryHash屬性中可以查看。

Plan_generation_num列顯示一個(gè)查詢被重編譯的次數(shù)。

SQLServer優(yōu)化器嘗試選擇能提供最快響應(yīng)時(shí)間的執(zhí)行計(jì)劃，但是不代表總是低CPU利用。低效的查詢計(jì)劃會(huì)引起CPU的好用，此時(shí)同樣可以使用sys.dm_exec_query_stats 來(lái)監(jiān)控。

如果你想有一個(gè)對(duì)SQLServer優(yōu)化所耗費(fèi)時(shí)間的總覽，可以檢查：

sys.dm_exec_query_optimizer_info 。其中的消耗時(shí)間和最后開(kāi)銷會(huì)非常有用。

可以使用以下DMVs來(lái)查詢內(nèi)部并行查詢及其查詢文本、執(zhí)行計(jì)劃的情況：

sys.dm_exec_cached_plan: Shows the cached query plans.

sys.dm_exec_requests: Shows each executing request in the SQL Server instance.

sys.dm_exec_sessions: Shows all active user connections and internal tasks.

sys.dm_exec_sql_text: Shows the text of the SQL batches.

sys.dm_os_tasks: Shows each active task within SQL Server.

SQL Server Profiler:

如果性能監(jiān)視器發(fā)現(xiàn)有問(wèn)題，同樣可以使用SQLServer Profiler來(lái)發(fā)現(xiàn)不必要的編譯和重編譯。SQLServer Profiler 跟蹤能幫助你找到一直重編譯的存儲(chǔ)過(guò)程。可以使用下面的事件：

SP:Recompile, CursorRecompile, SQL:StmtRecompile: 這個(gè)事件是針對(duì)SQLServer的重編譯。SP:Recompile事件中的EventSubClass 說(shuō)明了重編譯的原因。

· Showplan XML For Query Compile: 這個(gè)事件是針對(duì)T-SQL語(yǔ)句的重編譯。包含了查詢計(jì)劃和過(guò)程的對(duì)象ID.注意對(duì)這個(gè)事件運(yùn)行一個(gè)跟蹤，能得到利用系統(tǒng)資源的重要信息。但是，如果性能計(jì)數(shù)器報(bào)告SQL Compilations/sec 的值很高時(shí)，跟蹤將非常好資源。

低效的游標(biāo)可以使用RPC:Completed事件來(lái)跟蹤。查看sp_cursorfetch語(yǔ)句并檢查第四個(gè)參數(shù)，包含每次提前（fetch）包含的行數(shù)。

sql server 多表連接優(yōu)化，大表放在前邊好些，還是后邊？where條件放前邊表關(guān)聯(lián)那里會(huì)不會(huì)快些？

sql server 不像Oracle，它的查詢是自己分析并決定先后的，所以你不用考慮where的先后。

但是有一些where條件的優(yōu)化還是要考慮的，比如 =或exists 比 in 效率高等，具體你可以上網(wǎng)查。

SQL有一個(gè)功能叫“顯示估計(jì)的執(zhí)行計(jì)劃”（在分析的藍(lán)色勾右面，仔細(xì)找便可找到）

它會(huì)幫你分析執(zhí)行計(jì)劃，并給出相關(guān)的優(yōu)化建議

你也可以根據(jù)分析結(jié)果，相應(yīng)建INDEX等方式優(yōu)化查詢。

如何利用索引提高SQLServer數(shù)據(jù)處理的效率

在良好的數(shù)據(jù)庫(kù)設(shè)計(jì)基礎(chǔ)上，能有效地使用索引是SQL Server取得高性能的基礎(chǔ)，SQL Server采用基于代價(jià)的優(yōu)化模型，它對(duì)每一個(gè)提交的有關(guān)表的查詢，決定是否使用索引或用哪一個(gè)索引。因?yàn)椴樵儓?zhí)行的大部分開(kāi)銷是磁盤I/O，使用索引提高性能的一個(gè)主要目標(biāo)是避免全表掃描，因?yàn)槿頀呙栊枰獜拇疟P上讀表的每一個(gè)數(shù)據(jù)頁(yè)，如果有索引指向數(shù)據(jù)值，則查詢只需讀幾次磁盤就可以了。

所以如果建立了合理的索引，優(yōu)化器就能利用索引加速數(shù)據(jù)的查詢過(guò)程。但是，索引并不總是提高系統(tǒng)的性能，在增、刪、改操作中索引的存在會(huì)增加一定的工作量，因此，在適當(dāng)?shù)牡胤皆黾舆m當(dāng)?shù)乃饕牟缓侠淼牡胤絼h除次優(yōu)的索引，將有助于優(yōu)化那些性能較差的SQL Server應(yīng)用。實(shí)踐表明，合理的索引設(shè)計(jì)是建立在對(duì)各種查詢的分析和預(yù)測(cè)上的，只有正確地使索引與程序結(jié)合起來(lái),才能產(chǎn)生最佳的優(yōu)化方案。本文就SQL Server索引的性能問(wèn)題進(jìn)行了一些分析和實(shí)踐。

一、聚簇索引(clustered indexes)的使用

聚簇索引是一種對(duì)磁盤上實(shí)際數(shù)據(jù)重新組織以按指定的一個(gè)或多個(gè)列的值排序。由于聚簇索引的索引頁(yè)面指針指向數(shù)據(jù)頁(yè)面，所以使用聚簇索引查找數(shù)據(jù)幾乎總是比使用非聚簇索引快。每張表只能建一個(gè)聚簇索引，并且建聚簇索引需要至少相當(dāng)該表120%的附加空間，以存放該表的副本和索引中間頁(yè)。建立聚簇索引的思想是：

1、大多數(shù)表都應(yīng)該有聚簇索引或使用分區(qū)來(lái)降低對(duì)表尾頁(yè)的競(jìng)爭(zhēng)，在一個(gè)高事務(wù)的環(huán)境中，對(duì)最后一頁(yè)的封鎖嚴(yán)重影響系統(tǒng)的吞吐量。

2、在聚簇索引下，數(shù)據(jù)在物理上按順序排在數(shù)據(jù)頁(yè)上，重復(fù)值也排在一起，因而在那些包含范圍檢查(between、、=、、=)或使用group by或order by的查詢時(shí)，一旦找到具有范圍中第一個(gè)鍵值的行，具有后續(xù)索引值的行保證物理上毗連在一起而不必進(jìn)一步搜索，避免了大范圍掃描，可以大大提高查詢速度。

3、在一個(gè)頻繁發(fā)生插入操作的表上建立聚簇索引時(shí)，不要建在具有單調(diào)上升值的列(如IDENTITY)上，否則會(huì)經(jīng)常引起封鎖沖突。

4、在聚簇索引中不要包含經(jīng)常修改的列，因?yàn)榇a值修改后，數(shù)據(jù)行必須移動(dòng)到新的位置。

5、選擇聚簇索引應(yīng)基于where子句和連接操作的類型。

聚簇索引的侯選列是：

1、主鍵列,該列在where子句中使用并且插入是隨機(jī)的。

2、按范圍存取的列，如pri_order 100 and pri_order 200。

3、在group by或order by中使用的列。

4、不經(jīng)常修改的列。

5、在連接操作中使用的列。

二、非聚簇索引(nonclustered indexes)的使用

SQL Server缺省情況下建立的索引是非聚簇索引，由于非聚簇索引不重新組織表中的數(shù)據(jù)，而是對(duì)每一行存儲(chǔ)索引列值并用一個(gè)指針指向數(shù)據(jù)所在的頁(yè)面。換句話說(shuō)非聚簇索引具有在索引結(jié)構(gòu)和數(shù)據(jù)本身之間的一個(gè)額外級(jí)。一個(gè)表如果沒(méi)有聚簇索引時(shí),可有250個(gè)非聚簇索引。每個(gè)非聚簇索引提供訪問(wèn)數(shù)據(jù)的不同排序順序。在建立非聚簇索引時(shí)，要權(quán)衡索引對(duì)查詢速度的加快與降低修改速度之間的利弊。另外，還要考慮這些問(wèn)題：

1、索引需要使用多少空間。

2、合適的列是否穩(wěn)定。

3、索引鍵是如何選擇的，掃描效果是否更佳。

4、是否有許多重復(fù)值。

對(duì)更新頻繁的表來(lái)說(shuō)，表上的非聚簇索引比聚簇索引和根本沒(méi)有索引需要更多的額外開(kāi)銷。對(duì)移到新頁(yè)的每一行而言，指向該數(shù)據(jù)的每個(gè)非聚簇索引的頁(yè)級(jí)行也必須更新，有時(shí)可能還需要索引頁(yè)的分理。從一個(gè)頁(yè)面刪除數(shù)據(jù)的進(jìn)程也會(huì)有類似的開(kāi)銷，另外，刪除進(jìn)程還必須把數(shù)據(jù)移到頁(yè)面上部，以保證數(shù)據(jù)的連續(xù)性。所以，建立非聚簇索引要非常慎重。非聚簇索引常被用在以下情況：

1、某列常用于集合函數(shù)(如Sum,....)。

2、某列常用于join,order by,group by。

3、查尋出的數(shù)據(jù)不超過(guò)表中數(shù)據(jù)量的20%。

三、覆蓋索引(covering indexes)的使用

覆蓋索引是指那些索引項(xiàng)中包含查尋所需要的全部信息的非聚簇索引，這種索引之所以比較快也正是因?yàn)樗饕?yè)中包含了查尋所必須的數(shù)據(jù),不需去訪問(wèn)數(shù)據(jù)頁(yè)。如果非聚簇索引中包含結(jié)果數(shù)據(jù),那么它的查詢速度將快于聚簇索引。

但是由于覆蓋索引的索引項(xiàng)比較多,要占用比較大的空間。而且update操作會(huì)引起索引值改變。所以如果潛在的覆蓋查詢并不常用或不太關(guān)鍵，則覆蓋索引的增加反而會(huì)降低性能。

四、索引的選擇技術(shù)

p_detail是住房公積金管理系統(tǒng)中記錄個(gè)人明細(xì)的表，有890000行，觀察在不同索引下的查詢運(yùn)行效果，測(cè)試在C/S環(huán)境下進(jìn)行，客戶機(jī)是IBM PII350(內(nèi)存64M),服務(wù)器是DEC Alpha1000A(內(nèi)存128M),數(shù)據(jù)庫(kù)為SYBASE11.0.3。

1、 select count(*) from p_detail where

op_date’19990101’ and op_date’

19991231’ and pri_surplus1300

2、 select count(*),sum(pri_surplus1) from p_detail

where op_date’19990101’ and

pay_month between‘199908’ and’199912’

不建任何索引查詢1 1分15秒

查詢2 1分7秒

在op_date上建非聚簇索引查詢1 57秒

查詢2 57秒

在op_date上建聚簇索引查詢1 1秒

查詢2 52秒

在pay_month、op_date、pri_surplus1上建索引查詢1 34秒

查詢2 1秒

在op_date、pay_month、pri_surplus1上建索引查詢1 1秒

查詢2 1秒

從以上查詢效果分析，索引的有無(wú)，建立方式的不同將會(huì)導(dǎo)致不同的查詢效果，選擇什么樣的索引基于用戶對(duì)數(shù)據(jù)的查詢條件,這些條件體現(xiàn)于where從句和join表達(dá)式中。一般來(lái)說(shuō)建立索引的思路是：

(1)主鍵時(shí)常作為where子句的條件，應(yīng)在表的主鍵列上建立聚簇索引，尤其當(dāng)經(jīng)常用它作為連接的時(shí)候。

(2)有大量重復(fù)值且經(jīng)常有范圍查詢和排序、分組發(fā)生的列，或者非常頻繁地被訪問(wèn)的列，可考慮建立聚簇索引。

(3)經(jīng)常同時(shí)存取多列，且每列都含有重復(fù)值可考慮建立復(fù)合索引來(lái)覆蓋一個(gè)或一組查詢，并把查詢引用最頻繁的列作為前導(dǎo)列，如果可能盡量使關(guān)鍵查詢形成覆蓋查詢。

(4)如果知道索引鍵的所有值都是唯一的，那么確保把索引定義成唯一索引。

(5)在一個(gè)經(jīng)常做插入操作的表上建索引時(shí)，使用fillfactor(填充因子)來(lái)減少頁(yè)分裂，同時(shí)提高并發(fā)度降低死鎖的發(fā)生。如果在只讀表上建索引，則可以把fillfactor置為100。

(6)在選擇索引鍵時(shí)，設(shè)法選擇那些采用小數(shù)據(jù)類型的列作為鍵以使每個(gè)索引頁(yè)能夠容納盡可能多的索引鍵和指針，通過(guò)這種方式，可使一個(gè)查詢必須遍歷的索引頁(yè)面降到最小。此外，盡可能地使用整數(shù)為鍵值，因?yàn)樗軌蛱峁┍热魏螖?shù)據(jù)類型都快的訪問(wèn)速度。

五、索引的維護(hù)

上面講到,某些不合適的索引影響到SQL Server的性能,隨著應(yīng)用系統(tǒng)的運(yùn)行,數(shù)據(jù)不斷地發(fā)生變化,當(dāng)數(shù)據(jù)變化達(dá)到某一個(gè)程度時(shí)將會(huì)影響到索引的使用。這時(shí)需要用戶自己來(lái)維護(hù)索引。索引的維護(hù)包括：

1、重建索引

隨著數(shù)據(jù)行的插入、刪除和數(shù)據(jù)頁(yè)的分裂，有些索引頁(yè)可能只包含幾頁(yè)數(shù)據(jù)，另外應(yīng)用在執(zhí)行大塊I/O的時(shí)候，重建非聚簇索引可以降低分片，維護(hù)大塊I/O的效率。重建索引實(shí)際上是重新組織B-樹(shù)空間。在下面情況下需要重建索引：

(1)數(shù)據(jù)和使用模式大幅度變化。

(2)排序的順序發(fā)生改變。

(3)要進(jìn)行大量插入操作或已經(jīng)完成。

(4)使用大塊I/O的查詢的磁盤讀次數(shù)比預(yù)料的要多。

(5)由于大量數(shù)據(jù)修改，使得數(shù)據(jù)頁(yè)和索引頁(yè)沒(méi)有充分使用而導(dǎo)致空間的使用超出估算。

(6)dbcc檢查出索引有問(wèn)題。

當(dāng)重建聚簇索引時(shí)，這張表的所有非聚簇索引將被重建。

2、索引統(tǒng)計(jì)信息的更新

當(dāng)在一個(gè)包含數(shù)據(jù)的表上創(chuàng)建索引的時(shí)候，SQL Server會(huì)創(chuàng)建分布數(shù)據(jù)頁(yè)來(lái)存放有關(guān)索引的兩種統(tǒng)計(jì)信息：分布表和密度表。優(yōu)化器利用這個(gè)頁(yè)來(lái)判斷該索引對(duì)某個(gè)特定查詢是否有用。但這個(gè)統(tǒng)計(jì)信息并不動(dòng)態(tài)地重新計(jì)算。這意味著，當(dāng)表的數(shù)據(jù)改變之后，統(tǒng)計(jì)信息有可能是過(guò)時(shí)的，從而影響優(yōu)化器追求最有工作的目標(biāo)。因此，在下面情況下應(yīng)該運(yùn)行update statistics命令：

(1)數(shù)據(jù)行的插入和刪除修改了數(shù)據(jù)的分布。

(2)對(duì)用truncate table刪除數(shù)據(jù)的表上增加數(shù)據(jù)行。

(3)修改索引列的值。

六、結(jié)束語(yǔ)

實(shí)踐表明，不恰當(dāng)?shù)乃饕坏谑聼o(wú)補(bǔ)，反而會(huì)降低系統(tǒng)的執(zhí)行性能。因?yàn)榇罅康乃饕诓迦搿⑿薷暮蛣h除操作時(shí)比沒(méi)有索引花費(fèi)更多的系統(tǒng)時(shí)間。例如下面情況下建立的索引是不恰當(dāng)?shù)模?/p>

1、在查詢中很少或從不引用的列不會(huì)受益于索引，因?yàn)樗饕苌倩驈膩?lái)不必搜索基于這些列的行。

2、只有兩個(gè)或三個(gè)值的列，如男性和女性(是或否)，從不會(huì)從索引中得到好處。

另外，鑒于索引加快了查詢速度，但減慢了數(shù)據(jù)更新速度的特點(diǎn)。可通過(guò)在一個(gè)段上建表，而在另一個(gè)段上建其非聚簇索引，而這兩段分別在單獨(dú)的物理設(shè)備上來(lái)改善操作性能。

sqlserver 怎么樣優(yōu)化性能

SQL Server數(shù)據(jù)庫(kù)查詢速度慢的原因有很多，常見(jiàn)的有以下幾種：

1、沒(méi)有索引或者沒(méi)有用到索引(這是查詢慢最常見(jiàn)的問(wèn)題，是數(shù)據(jù)庫(kù)設(shè)計(jì)的缺陷)

2、I/O吞吐量小，形成了瓶頸效應(yīng)。

3、沒(méi)有創(chuàng)建計(jì)算列導(dǎo)致查詢不優(yōu)化。

4、內(nèi)存不足

5、網(wǎng)絡(luò)速度慢

6、查詢出的數(shù)據(jù)量過(guò)大（可以采用多次查詢，其他的方法降低數(shù)據(jù)量）

7、鎖或者死鎖(這也是查詢慢最常見(jiàn)的問(wèn)題，是程序設(shè)計(jì)的缺陷)

8、sp_lock,sp_who,活動(dòng)的用戶查看,原因是讀寫(xiě)競(jìng)爭(zhēng)資源。

9、返回了不必要的行和列

10、查詢語(yǔ)句不好，沒(méi)有優(yōu)化

●可以通過(guò)以下方法來(lái)優(yōu)化查詢 :

1、把數(shù)據(jù)、日志、索引放到不同的I/O設(shè)備上，增加讀取速度，以前可以將Tempdb應(yīng)放在RAID0上，SQL2000不在支持。數(shù)據(jù)量（尺寸）越大，提高I/O越重要。

2、縱向、橫向分割表，減少表的尺寸(sp_spaceuse)

3、升級(jí)硬件

4、根據(jù)查詢條件,建立索引,優(yōu)化索引、優(yōu)化訪問(wèn)方式，限制結(jié)果集的數(shù)據(jù)量。注意填充因子要適當(dāng)（最好是使用默認(rèn)值0）。索引應(yīng)該盡量小，使用字節(jié)數(shù)小的列建索引好（參照索引的創(chuàng)建）,不要對(duì)有限的幾個(gè)值的字段建單一索引如性別字段。

5、提高網(wǎng)速。

6、擴(kuò)大服務(wù)器的內(nèi)存,Windows 2000和SQL server 2000能支持4-8G的內(nèi)存。

配置虛擬內(nèi)存：虛擬內(nèi)存大小應(yīng)基于計(jì)算機(jī)上并發(fā)運(yùn)行的服務(wù)進(jìn)行配置。運(yùn)行 Microsoft SQL Server? 2000時(shí)，可考慮將虛擬內(nèi)存大小設(shè)置為計(jì)算機(jī)中安裝的物理內(nèi)存的1.5倍。如果另外安裝了全文檢索功能，并打算運(yùn)行Microsoft搜索服務(wù)以便執(zhí)行全文索引和查詢，可考慮：將虛擬內(nèi)存大小配置為至少是計(jì)算機(jī)中安裝的物理內(nèi)存的3倍。將SQL Server max server memory服務(wù)器配置選項(xiàng)配置為物理內(nèi)存的1.5倍（虛擬內(nèi)存大小設(shè)置的一半）。

7、增加服務(wù)器CPU個(gè)數(shù);但是必須 明白并行處理串行處理更需要資源例如內(nèi)存。使用并行還是串行程是MSSQL自動(dòng)評(píng)估選擇的。單個(gè)任務(wù)分解成多個(gè)任務(wù)，就可以在處理器上運(yùn)行。例如耽擱查詢 的排序、連接、掃描和GROUP BY字句同時(shí)執(zhí)行，SQL SERVER根據(jù)系統(tǒng)的負(fù)載情況決定最優(yōu)的并行等級(jí)，復(fù)雜的需要消耗大量的CPU的查詢最適合并行處理。但是更新操作UPDATE,INSERT， DELETE還不能并行處理。

8、如果是使用like進(jìn)行查詢的話，簡(jiǎn)單的使用index是不行的，但是全文索引，耗空間。 like ''a%'' 使用索引 like ''%a'' 不使用索引用 like ''%a%'' 查詢時(shí)，查詢耗時(shí)和字段值總長(zhǎng)度成正比,所以不能用CHAR類型，而是VARCHAR。對(duì)于字段的值很長(zhǎng)的建全文索引。

9、DB Server 和APPLication Server 分離；OLTP和OLAP分離

10、分布式分區(qū)視圖可用于實(shí)現(xiàn)數(shù)據(jù)庫(kù)服務(wù)器聯(lián)合體。

聯(lián)合體是一組分開(kāi)管理的服務(wù)器，但它們相互協(xié)作分擔(dān)系統(tǒng)的處理負(fù)荷。這種通過(guò)分區(qū)數(shù)據(jù)形成數(shù)據(jù)庫(kù)服務(wù)器聯(lián)合體的機(jī)制能夠擴(kuò)大一組服務(wù)器，以支持大型的多層 Web 站點(diǎn)的處理需要。有關(guān)更多信息，參見(jiàn)設(shè)計(jì)聯(lián)合數(shù)據(jù)庫(kù)服務(wù)器。（參照SQL幫助文件''分區(qū)視圖''）

a、在實(shí)現(xiàn)分區(qū)視圖之前，必須先水平分區(qū)表

b、 在創(chuàng)建成員表后，在每個(gè)成員服務(wù)器上定義一個(gè)分布式分區(qū)視圖，并且每個(gè)視圖具有相同的名稱。這樣，引用分布式分區(qū)視圖名的查詢可以在任何一個(gè)成員服務(wù)器上 運(yùn)行。系統(tǒng)操作如同每個(gè)成員服務(wù)器上都有一個(gè)原始表的復(fù)本一樣，但其實(shí)每個(gè)服務(wù)器上只有一個(gè)成員表和一個(gè)分布式分區(qū)視圖。數(shù)據(jù)的位置對(duì)應(yīng)用程序是透明的。

11、重建索引 DBCC REINDEX ,DBCC INDEXDEFRAG,收縮數(shù)據(jù)和日志 DBCC SHRINKDB,DBCC SHRINKFILE. 設(shè)置自動(dòng)收縮日志.對(duì)于大的數(shù)據(jù)庫(kù)不要設(shè)置數(shù)據(jù)庫(kù)自動(dòng)增長(zhǎng)，它會(huì)降低服務(wù)器的性能。

在T-sql的寫(xiě)法上有很大的講究，下面列出常見(jiàn)的要點(diǎn)：首先，DBMS處理查詢計(jì)劃的過(guò)程是這樣的：

1、 查詢語(yǔ)句的詞法、語(yǔ)法檢查

2、 將語(yǔ)句提交給DBMS的查詢優(yōu)化器

3、 優(yōu)化器做代數(shù)優(yōu)化和存取路徑的優(yōu)化

4、 由預(yù)編譯模塊生成查詢規(guī)劃

5、 然后在合適的時(shí)間提交給系統(tǒng)處理執(zhí)行

6、 最后將執(zhí)行結(jié)果返回給用戶。

其次，看一下SQL SERVER的數(shù)據(jù)存放的結(jié)構(gòu)：一個(gè)頁(yè)面的大小為8K(8060)字節(jié)，8個(gè)頁(yè)面為一個(gè)盤區(qū)，按照B樹(shù)存放。

名稱欄目：sqlserver優(yōu)化器,sqlserver 性能優(yōu)化
標(biāo)題URL：http://chinadenli.net/article37/dsshdsj.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供建站公司、營(yíng)銷型網(wǎng)站建設(shè)、網(wǎng)站導(dǎo)航、關(guān)鍵詞優(yōu)化、Google、微信小程序

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)