⑴ sqlserver 優化,具體怎麼優化 不要混分的.
1 條件列都建單鍵索引，isnull的列建函數索引
2 如果可能，不用or，in，盡量用union改寫
3 如果是日常操作，游標肯定得要，因為你更改狀態後，還要插入日誌
4 如果是一次性處理，可以再保證沒有別人用的情況下，
用 insert into history ... select ... 的寫法寫日誌
用update ... from 的方法 統一更新訂單狀態，
然後統一commit即可
⑵ SQLServer求優化
我一不太會優化，提供你一些優化的方法吧
操作符優化
in 操作符
用in寫出來的sql的優點是比較容易寫及清晰易懂，這比較適合現代軟體開發的風格。
但是用in的sql性能總是比較低的，從oracle執行的步驟來分析用in的sql與不用in的sql有以下區別：
oracle試圖將其轉換成多個表的連接，如果轉換不成功則先執行in裡面的子查詢，再查詢外層的表記錄，如果轉換成功則直接採用多個表的連接方式查詢。由此可見用in的sql至少多了一個轉換的過程。一般的sql都可以轉換成功，但對於含有分組統計等方面的sql就不能轉換了。
推薦方案：在業務密集的sql當中盡量不採用in操作符。
not in操作符
此操作是強列推薦不使用的，因為它不能應用表的索引。
推薦方案：用not exists 或（外連接+判斷為空）方案代替
<> 操作符（不等於）
不等於操作符是永遠不會用到索引的，因此對它的處理只會產生全表掃描。
推薦方案：用其它相同功能的操作運算代替，如
a<>0 改為 a>0 or a<0
a<>』』 改為 a>』』
is null 或is not null操作（判斷欄位是否為空）
判斷欄位是否為空一般是不會應用索引的，因為b樹索引是不索引空值的。
推薦方案：用其它相同功能的操作運算代替，如
a is not null 改為 a>0 或a>』』等。
不允許欄位為空，而用一個預設值代替空值，如業擴申請中狀態欄位不允許為空，預設為申請。
建立點陣圖索引（有分區的表不能建，點陣圖索引比較難控制，如欄位值太多索引會使性能下降，多人更新操作會增加數據塊鎖的現象）
> 及 < 操作符（大於或小於操作符）
大於或小於操作符一般情況下是不用調整的，因為它有索引就會採用索引查找，但有的情況下可以對它進行優化，如一個表有100萬記錄，一個數值型欄位a，30萬記錄的a=0，30萬記錄的a=1，39萬記錄的a=2，1萬記錄的a=3。那麼執行a>2與a>=3的效果就有很大的區別了，因為a>2時oracle會先找出為2的記錄索引再進行比較，而a>=3時oracle則直接找到=3的記錄索引。
like操作符
like操作符可以應用通配符查詢，裡面的通配符組合可能達到幾乎是任意的查詢，但是如果用得不好則會產生性能上的問題，如like 『%5400%』 這種查詢不會引用索引，而like 『x5400%』則會引用范圍索引。一個實際例子：用yw_yhjbqk表中營業編號後面的戶標識號可來查詢營業編號 yy_bh like 『%5400%』 這個條件會產生全表掃描，如果改成yy_bh like 』x5400%』 or yy_bh like 』b5400%』 則會利用yy_bh的索引進行兩個范圍的查詢，性能肯定大大提高。
union操作符
union在進行表鏈接後會篩選掉重復的記錄，所以在表鏈接後會對所產生的結果集進行排序運算，刪除重復的記錄再返回結果。實際大部分應用中是不會產生重復的記錄，最常見的是過程表與歷史表union。如：
select * from gc_dfys
union
select * from ls_jg_dfys
這個sql在運行時先取出兩個表的結果，再用排序空間進行排序刪除重復的記錄，最後返回結果集，如果表數據量大的話可能會導致用磁碟進行排序。
推薦方案：採用union all操作符替代union，因為union all操作只是簡單的將兩個結果合並後就返回。
select * from gc_dfys
union all
select * from ls_jg_dfys
sql語句索引的利用
對條件欄位的一些優化
採用函數處理的欄位不能利用索引，如：
substr(hbs_bh,1,4)=』5400』，優化處理：hbs_bh like 『5400%』
trunc(sk_rq)=trunc(sysdate)， 優化處理：
sk_rq>=trunc(sysdate) and sk_rq
進行了顯式或隱式的運算的欄位不能進行索引，如：
ss_df+20>50，優化處理：ss_df>30
『x』||hbs_bh>』x5400021452』，優化處理：hbs_bh>』5400021542』
sk_rq+5=sysdate，優化處理：sk_rq=sysdate-5
hbs_bh=5401002554，優化處理：hbs_bh=』 5401002554』，註：此條件對hbs_bh 進行隱式的to_number轉換，因為hbs_bh欄位是字元型。
條件內包括了多個本表的欄位運算時不能進行索引，如：
ys_df>cx_df，無法進行優化
qc_bh||kh_bh=』5400250000』，優化處理：qc_bh=』5400』 and kh_bh=』250000』
應用oracle的hint（提示）處理
提示處理是在oracle產生的sql分析執行路徑不滿意的情況下要用到的。它可以對sql進行以下方面的提示
目標方面的提示：
cost（按成本優化）
rule（按規則優化）
choose（預設）（oracle自動選擇成本或規則進行優化）
all_rows（所有的行盡快返回）
first_rows（第一行數據盡快返回）
執行方法的提示：
use_nl（使用nested loops方式聯合）
use_merge（使用merge join方式聯合）
use_hash（使用hash join方式聯合）
索引提示：
index（table index）（使用提示的表索引進行查詢）
其它高級提示（如並行處理等等）
oracle的提示功能是比較強的功能，也是比較復雜的應用，並且提示只是給oracle執行的一個建議，有時如果出於成本方面的考慮oracle也可能不會按提示進行。根據實踐應用，一般不建議開發人員應用oracle提示，因為各個資料庫及伺服器性能情況不一樣，很可能一個地方性能提升了，但另一個地方卻下降了，oracle在sql執行分析方面已經比較成熟，如果分析執行的路徑不對首先應在資料庫結構（主要是索引）、伺服器當前性能（共享內存、磁碟文件碎片）、資料庫對象（表、索引）統計信息是否正確這幾方面分析。
⑶ 淺談如何優化SQL Server伺服器
數據和日誌文件分開存放在不同磁碟上
數據文件和日誌文件的操作會產生大量的I/O 在可能的條件下 日誌文件應該存放在一個與數據和索引所在的數據文件不同的硬碟上以分散I/O 同時還有利於資料庫的災難恢復
tempdb資料庫單獨存放在不同磁碟上
tempdb資料庫是其他所有資料庫都有可能使用的臨時資料庫 當使用select into 在沒建立索引的列上執行Orderby時就會在tempdb資料庫中產生臨時表來存儲中間數據 由於建立和填充臨時表會嚴重降低系統性能 所以在盡可能的情況下應該為要排序的列建立索引 同時 tempdb資料庫是為所有的用戶和應用程序共享 所以如果一個用戶占據了tempdb資料庫的所有空間 則其他資料庫將不能再使用 在可能的情況下 tempdb資料庫應該單獨放置在一個速度更快的硬碟或者RAID陣列上 分離tempdb資料庫的I/O操作以加快性能 tempdb資料庫應該有適當的容量 以滿足用戶的需要 應該允許tempdb資料庫的空間自動增長 如果設置為不允許自動增長 當查詢操作建立了超過tempdb資料庫容量的臨時表時 操作將無法完成
適當設置tempdb資料庫的增長幅度 過小的增長幅度會產生更多的外部碎片 會佔用更多的資源
避免熱點數據的發生
在SQLServer 之前 對於沒有聚集索引的表（堆集表） 新插入的數據行總是放置在磁碟中表的物理結尾處 如果並發的用戶很多 同時在對表執行插入或者更新數據的操作 這將使得十分繁忙的表的末尾有可能產生數據熱點 並發的I/O操作集中對少數頁面進行操作 將導致資料庫性能的下降
在SQLServer中 新的數據行的物理存儲空間的分配是通過PFS頁面來進行的 PFS頁面的管理演算法將插入操作進行分散來盡量避免產生數據熱點
在設計應用系統和資料庫時 要避免在自然增長的列上建立主鍵 這樣有可能導致熱點數據的發生
數據類型要少
在設計表時 盡可能少用數據類型 這樣一個數據頁面上可以保存最多的信息 數據頁面就少 檢索數據頁面的I/O操作就少 所以效率會高
監控和整理空間碎片
文件空間的自動增長提高了自動管理性 但可能導致空間碎片 物理空間與數據的邏輯空間不再連續 定期的監控和空間碎片整理有利於提高I/O性能
使用主數據文件和次要數據文件
每個資料庫的一個主數據文件屬於主文件組 對於 GB左右規模的資料庫 一個數據文件就夠了 如果有次要數據文件 主數據文件中有管理次要數據文件的指針
採用多個數據文件時 主數據文件用於存儲系統對象和表 次要數據文件用於存儲用戶數據和索引 在可能的情況下 主數據文件和次要數據文件可以單獨存放在不同的磁碟上以分散I/O
如果採用多個數據文件 推薦主數據文件存儲系統數據 次要數據文件存放用戶數據和索引 這樣會有助於提高I/O性能
利用文件組改善性能
在大型資料庫系統中 可以考慮建立文件組來管理數據文件 將表和索引通過存放在不同的物理磁碟上進行性能監控比較 最後得出優化的存儲方案
重視自動增長和自動收縮可能導致的性能問題
資料庫文件的自動增長和自動收縮功能對於小型資料庫的管理十分有用 但可能導致大型資料庫的性能問題 因為文件的自然增長的同時會導致存儲碎片的發生 當文件空間變大時 新分配的空間不一定和原來的空間連續 當文件空間收縮時 釋放了部分空間 然而當文件又需要增長存儲空間卻不能利用原先釋放的空間 也會導致碎片的發生
分離系統數據和用戶數據
將系統資料庫和用戶資料庫分開存放在不同的物理磁碟上有助於改善I/O性能 有助於資料庫備份和恢復
優化索引設計
索引的設計對資料庫的性能十分重要 具體不再闡述 可參見本博相關文章
定期更新統計信息
SQLServer默認使用基於代價的優化 所以統計信息的及時更新對於查詢優化十分重要
定期的一致性檢查
lishixin/Article/program/SQLServer/201311/22434
⑷ 如何做SqlServer 數據查詢優化！
一、建立索引
二、建立存儲過程
三、只查詢您所需要的數據，不要把所有數據都查詢出來，防止數據冗餘。
四、對於大量及海量數據一般還要建立分區
⑸ SQLserver 大批量更新插入的時候游標怎麼優化
盡量避免使用游標，因為游標的效率較差，如果游標操作的數據超過1萬行，那麼就應該考慮改寫。
使用基於游標的方法之前，應先尋找基於集的解決方案來解決問題，基於集的方法通常更有效。
最好的改進游標性能的技術就是：能避免時就避免使用游標
若有時無法避免使用游標，則可以用如下技巧來優化游標的性能。
(1). 除非必要否則不要使用static/insensitive游標。打開static游標會造成所有的行都被拷貝到臨時表。這正是為什麼它對變化不敏感的原因——它實際上是指向臨時資料庫表中的一個備份。很自然，結果集越大，聲明其上的static游標就會引起越多的臨時資料庫的資源爭奪問題。
(2). 除非必要否則不要使用keyset游標。和static游標一樣，打開keyset游標會創建臨時表。雖然這個表只包括基本表的一個關鍵字列(除非不存在唯一關鍵字)，但是當處理大結果集時還是會相當大的。
(3). 當處理單向的只讀結果集時，使用fast_forward代替forward_only。使用fast_forward定義一個forward_only，則read_only游標具有一定的內部性能優化。
(4). 使用read_only關鍵字定義只讀游標。這樣可以防止意外的修改，並且讓伺服器了解游標移動時不會修改行。
(5). 小心事務處理中通過游標進行的大量行修改。根據事務隔離級別，這些行在事務完成或回滾前會保持鎖定，這可能造成伺服器上的資源爭奪。
(6). 小心動態游標的修改，尤其是建在非唯一聚集索引鍵的表上的游標，因為他們會造成「Halloween」問題——對同一行或同一行的重復的錯誤的修改。因為SQL Server在內部會把某行的關鍵字修改成一個已經存在的值，並強迫伺服器追加下標，使它以後可以再結果集中移動。當從結果集的剩餘項中存取時，又會遇到那一行，然後程序會重復，結果造成死循環。
(7). 對於大結果集要考慮使用非同步游標，盡可能地把控制權交給調用者。當返回相當大的結果集到可移動的表格時，非同步游標特別有用，因為它們允許應用程序幾乎馬上就可以顯示行
⑹ 如何優化Sql server 大數據量時使用 like 查詢的速度或有什麼別的方法實現模糊查詢
傻逼啊，誰看了這個文章就是誤人子弟 方案1：主鍵Id，默認為聚集索引，不建立其它非聚集索引select * from News where Title like '%"&abigale&"%' or Author like '%"&abigale&"%' order by Id desc從欄位Title和Author中模糊檢索，按Id排序查詢時間：50秒方案2：主鍵Id，默認為聚集索引在Title、Author、Star上建立非聚集索引select * from News where Title like '"&abigale&"%' or Author like '"&abigale&"%' order by Id desc從欄位Title和Author中模糊檢索，按Id排序查詢時間：2 - 2.5秒 看到沒有，那個50秒用的是 '%"&abigale&"%'來的，兩個百分號會引發全表掃描而那個快的是 '"&abigale&"%' ，這樣就使用索引 不用索引和用索引完全兩個概念，尼瑪還在說優化，優化你妹
⑺ sql server資料庫查詢慢怎麼優化
在安裝有SQLServer資料庫的計算機上，我們在使用資料庫的過程中，有時候會在任務管理器里發現sqlservr.exe這個進程的內存和CPU佔用率較高。
接下來我們來看一下，如何解決上面這個問題，需要設置SQLServer資料庫的內存配置。登錄資料庫，這里使用的是SQLServer2008,右鍵點擊最上方的伺服器名，在彈出的菜單中，點擊【屬性】
打開伺服器屬性窗口。默認顯示的是第一項【常規】內容，點擊第二項【內存】進行內存配置。
點擊【內存】後，打開伺服器內存選項配置界面。這里的【使用AWE分配內存】可以對內存進行擴展支持，我們要做的是更改下方的最大伺服器內存。這個數值根據自己伺服器內存大小來做適當設置。
5
個人建議設置本機內存的一半或稍微高一點，如機器內存為2G，那麼我們這里填寫1000。需要注意的是內存設置調小以後，在資料庫執行較復雜SQL語句的時候，可能會比較慢，出現這種情況，我們再適當上調最大內存配置大小。
⑻ SQL Server資料庫的高性能優化經驗總結
本文主要向大家介紹的是正確優化SQL
Server資料庫的經驗總結，其中包括在對其進行優化的實際操作中值得大家注意的地方描述，以及對SQL語句進行優化的最基本原則，以下就是文章的主要內容描述。
優化資料庫的注意事項：
1、關鍵欄位建立索引。
2、使用存儲過程，它使SQL變得更加靈活和高效。
3、備份資料庫和清除垃圾數據。
4、SQL語句語法的優化。(可以用Sybase的SQL
Expert，可惜我沒找到unexpired的序列號)
5、清理刪除日誌。
SQL語句優化的基本原則：
1、使用索引來更快地遍歷表。
預設情況下建立的索引是非群集索引，但有時它並不是最佳的。在非群集索引下，數據在物理上隨機存放在數據頁上。合理的索引設計要建立在對各種查詢的分析和預測上。
一般來說：
①.有大量重復值、且經常有范圍查詢(between,
>,<
，>=,<
=)和order
by、group
by發生的列，可考慮建立群集索引
②.經常同時存取多列，且每列都含有重復值可考慮建立組合索引;
③.組合索引要盡量使關鍵查詢形成索引覆蓋，其前導列一定是使用最頻繁的列。
2、IS
NULL
與
IS
NOT
NULL
不能用null作索引，任何包含null值的列都將不會被包含在索引中。即使索引有多列這樣的情況下，只要這些列中有一列含有null，該列就會從索引中排除。也就是說如果某列存在空值，即使對該列建索引也不會提高性能。任何在where子句中使用is
null或is
not
null的語句優化器是不允許使用索引的。
3、IN和EXISTS
EXISTS要遠比IN的效率高。裡面關繫到full
table
scan和range
scan。幾乎將所有的IN操作符子查詢改寫為使用EXISTS的子查詢。
4、在海量查詢時盡量少用格式轉換。
5、當在SQL
SERVER
2000中
如果存儲過程只有一個參數，並且是OUTPUT類型的，必須在調用這個存儲過程的時候給這個參數一個初始的值，否則會出現調用錯誤。
6、ORDER
BY和GROPU
BY
使用ORDER
BY和GROUP
BY短語，任何一種索引都有助於SELECT的性能提高。注意如果索引列裡面有NULL值，Optimizer將無法優化。
7、任何對列的操作都將導致表掃描，它包括SQL
Server資料庫函數、計算表達式等等，查詢時要盡可能將操作移至等號右邊。
8、IN、OR子句常會使用工作表，使索引失效。如果不產生大量重復值，可以考慮把子句拆開。拆開的子句中應該包含索引。
9、SET
SHOWPLAN_ALL>10、謹慎使用游標
在某些必須使用游標的場合，可考慮將符合條件的數據行轉入臨時表中，再對臨時表定義游標進行操作，這樣可使性能得到明顯提高。
注釋：所謂的優化就是WHERE子句利用了索引，不可優化即發生了表掃描或額外開銷。經驗顯示，SQL
Server資料庫性能的最大改進得益於邏輯的資料庫設計、索引設計和查詢設計方面。反過來說，最大的性能問題常常是由其中這些相同方面中的不足引起的。
其實SQL優化的實質就是在結果正確的前提下，用優化器可以識別的語句，充份利用索引，減少表掃描的I/O次數，盡量避免表搜索的發生。其實SQL的性能優化是一個復雜的過程，上述這些只是在應用層次的一種體現，深入研究還會涉及SQL
Server資料庫層的資源配置、網路層的流量控制以及操作系統層的總體設計。