A. sql server 中 如何有效的提高性能
特別說明 在微軟的SQL Server系統中通過有效的使用索引可以提高資料庫的查詢性能，但是性能的提高取決於資料庫的實現。在本文中將會告訴你如何實現索引並有效的提高資料庫的性能。 在關系型資料庫中使用索引能夠提高資料庫性能，這一點是非常明顯的。用的索引越多，從資料庫系統中得到數據的速度就越快。然而，需要注意的是，用的索引越多，向資料庫系統中插入新數據所花費的時間就越多。在本文中，你將了解到微軟的SQL Server資料庫所支持的各種不同類型的索引，在這里你將了解到如何使用不同的方法來實現索引，通過這些不同的實現方法，你在資料庫的讀性能方面得到的遠比在資料庫的整體性能方面的損失要多得多。 索引的定義 索引是資料庫的工具，通過使用索引，在資料庫中獲取數據的時候，就可以不用掃描資料庫中的所有數據記錄，這樣能夠提高系統獲取數據的性能。使用索引可以改變數據的組織方式，使得所有的數據都是按照相似的結構來組織的，這樣就可以很容易地實現數據的檢索訪問。索引是按照列來創建的，這樣就可以根據索引列中的值來幫助資料庫找到相應的數據。 索引的類型 微軟的SQL Server 支持兩種類型的索引：clustered 索引和nonclustered索引。Clustered 索引在數據表中按照物理順序存儲數據。因為在表中只有一個物理順序，所以在每個表中只能有一個clustered索引。在查找某個范圍內的數據時，Clustered索引是一種非常有效的索引，因為這些數據在存儲的時候已經按照物理順序排好序了。 Nonclustered索引不會影響到下面的物理存儲，但是它是由數據行指針構成的。如果已經存在一個clustered索引，在nonclustered中的索引指針將包含clustered索引的位置參考。這些索引比數據更緊促，而且對這些索引的掃描速度比對實際的數據表掃描要快得多。 如何實現索引 資料庫可以自動創建某些索引。例如，微軟的SQL Server系統通過自動創建唯一索引來強制實現UNIQUE約束，這樣可以確保在資料庫中不會插入重復數據。也可以使用CREATE INDEX語句或者通過SQL Server Enterprise Manager來創建其他索引，SQL Server Enterprise Manager還有一個索引創建模板來指導你如何創建索引。 得到更好的性能 雖然索引可以帶來性能上的優勢，但是同時也將帶來一定的代價。雖然SQL Server系統允許你在每個數據表中創建多達256個nonclustered索引，但是建議不要使用這么多的索引。因為索引需要在內存和物理磁碟驅動器上使用更多的存儲空間。在執行插入聲明的過程中可能會在一定程度上導致系統性能的下降，因為在插入數據的時候是需要根據索引的順序插入，而不是在第一個可用的位置直接插入數據，這樣一來，存在的索引越多將導致插入或者更新聲明所需要的時間就越多。 在使用SQL Server系統創建索引的時候，建議參照下面的創建准則來實現： 正確的選擇數據類型 在索引中使用某些數據類型可以提高資料庫系統的效率，例如，Int，bigint， smallint，和tinyint等這些數據類型都非常適合於用在索引中，因為他們都佔用相同大小的空間並且可以很容易地實現比較操作。其他的數據類型如char和varchar的效率都非常低，因為這些數據類型都不適合於執行數學操作，並且執行比較操作的時間都比上面提到數據類型要長。 確保在使用的過程中正確的利用索引值 在執行查詢操作時，可能所使用的列只是clustered的一部分，這時尤其要注意的是如何使用這些數據。當用這些數據列作為參數調用函數時，這些函數可能會使現有的排序優勢失效。例如，使用日期值作為索引，而為了實現比較操作，可能需要將這個日期值轉換為字元串，這樣將導致在查詢過程中無法用到這個日期索引值。 在創建多列索引時，需要注意列的順序 資料庫將根據第一列索引的值來排列記錄，然後進一步根據第二列的值來排序，依次排序直到最後一個索引排序完畢。哪一列唯一數據值較少，哪一列就應該為第一個索引，這樣可以確保數據可以通過索引進一步交叉排序。 在clustered索引中限制列的數量 在clustered索引中用到的列越多，在nonclustered索引中包含的clustered索引參考位置就越多，需要存儲的數據也就越多。這樣將增加包含索引的數據表的大小，並且將增加基於索引的搜索時間。 避免頻繁更新clustered索引數據列 由於nonclustered 索引依賴於clustered 索引，所以如果構成clustered 索引的數據列頻繁更新，將導致在nonclustered中存儲的行定位器也將隨之頻繁更新。對於所有與這些列相關的查詢來說，如果發生記錄被鎖定的情況時，這將可能導致性能成本的增加。 分開操作（如果可能的話） 對於一個表來說，如果需要進行頻繁的執行插入、更新操作，同時還有大量讀操作的話，在可能的情況下嘗試將這個表分開操作。所有的插入和更新操作可以在一個沒有索引的表中操作，然後將其復制到另外一個表中，在這個表裡有大量的索引可以優化讀數據的能力。 適當的重建索引 Nonclustered索引包含clustered索引的指針，這樣一來Nonclustered索引將從屬於clustered 索引。當重建clustered索引時，首先是丟棄原來的索引，然後再使用CREATE INDEX 來創建索引，或者在使用CREATE INDEX 聲明的同時將DROP_EXISTING 子句作為重建索引的一部分。將丟棄和創建分為幾步將會導致多次重建nonclustered 索引，而不象使用DROP_EXISTING 子句那樣，只重建一次nonclustered 索引。 明智的使用填充因子 數據存儲在那些具有固定大小的連續內存頁面內。隨著新的記錄行的加入，數據內存頁將逐漸被填滿，系統就必須執行數據頁的拆分工作，通過這個拆分工作將部分數據轉移到下一個新的頁面當中。這樣的拆分之後，將加重系統的負擔，並且會導致存儲的數據支離破碎。填充因子可以維護數據之間的缺口，一般在創建索引的時候，該索引的填充因子就已經被設置好了。這樣一來，可以減少插入數據所引起的頁面分裂的次數。因為只是在創建索引的時候才維護空間的大小，在增加數據或者更新數據時不會去維護空間的大小。因此，要想能夠充分的利用填充因子，就必須周期性的重建索引。由填充因子所造成的缺口將導致讀性能的下降，因為隨著資料庫的擴張，越來越多的磁碟存取工作需要讀取數據。所以，在讀的次數超過寫的次數的時候，很重要的一點是考慮使用填充因子還是使用預設方式合適。 管理層的決策 通過有效的使用索引，可以在微軟的SQL Server系統中實現很好的查詢功能，但是使用索引的效率取決於幾種不同的實現決策。在索引的性能平衡方面，要做出正確的資料庫管理決策意味著需要在良好的性能和困境中抉擇。在特定的情況下，本文給出的一些建議將有助於你做出正確的決策。
B. sql語句性能如何優化
如何加快查詢速度?
1、升級硬體
2、根據查詢條件,建立索引,優化索引、優化訪問方式，限制結果集的數據量。
3、擴大伺服器的內存
4、增加伺服器CPU個數
5、對於大的資料庫不要設置資料庫自動增長，它會降低伺服器的性能
6、在查詢Select語句中用Where字句限制返回的行數,避免表掃描,如果返回不必要的數據，浪費了伺服器的I/O資源，加重了網路的負擔降低性能。如果表很大，在表掃描的期間將表鎖住，禁止其他的聯接訪問表,後果嚴重。
7、查詢時不要返回不需要的行、列
8、用select top 100 / 10 Percent 來限制用戶返回的行數或者SET ROWCOUNT來限制操作的行
9、在IN後面值的列表中，將出現最頻繁的值放在最前面，出現得最少的放在最後面，減少判斷的次數
10、一般在GROUP BY 個HAVING字句之前就能剔除多餘的行，所以盡量不要用它們來做剔除行的工作。他們的執行順序應該如下最優：
select的Where字句選擇所有合適的行，Group By用來分組個統計行，Having字句用來剔除多餘的分組。這樣Group By 個Having的開銷小，查詢快.對於大的數據行進行分組和Having十分消耗資源。如果Group BY的目的不包括計算，只是分組，那麼用Distinct更快
11、一次更新多條記錄比分多次更新每次一條快,就是說批處理好
C. SQL 多選一個欄位值只選一次 和多次從表裡查詢但查的欄位較少 相比哪個性能更好為什麼
這個要看你的數據量來決定.
SQL 多選一個欄位值只選一次
意味著你 只發送一次 SQL 語句， 然後獲得結果集合。
多次從表裡查詢但查的欄位較少
意味著你 發送了多個 SQL 語句， 然後分別獲得結果集合。
SQL 多次從一個表中查詢
耗費的是：
網路之間，要額外傳送SQL語句 （這個很多情況下，消耗可以忽略）
資料庫需要 分析你的 SQL語句的合法性，並做SQL的解析，並分析查詢計劃，並從多個查詢計劃中，選擇一個最優的查詢計劃，然後進行執行處理。 (這個過程消耗比較大，假如資料庫參數配置的好。或者開發語言處理的時候，就是按照 一條SQL，修改參數的方式處理的話，那麼消耗也不大)
D. sql 優化
最近幾周一直在進行資料庫培訓，老師精湛的技術和生動的講解使我受益匪淺。為了讓更多的新手受益，我抽空把SQL語句優化部分進行了整理，希望大家一起進步。
一、操作符優化
1、IN 操作符
用IN寫出來的SQL的優點是比較容易寫及清晰易懂，這比較適合現代軟體開發的風格。但是用IN的SQL性能總是比較低的，從Oracle執行的步驟來分析用IN的SQL與不用IN的SQL有以下區別：
ORACLE試圖將其轉換成多個表的連接，如果轉換不成功則先執行IN裡面的子查詢，再查詢外層的表記錄，如果轉換成功則直接採用多個表的連接方式查詢。由此可見用IN的SQL至少多了一個轉換的過程。一般的SQL都可以轉換成功，但對於含有分組統計等方面的SQL就不能轉換了。
推薦方案：在業務密集的SQL當中盡量不採用IN操作符，用EXISTS 方案代替。
2、NOT IN操作符
此操作是強列不推薦使用的，因為它不能應用表的索引。
推薦方案：用NOT EXISTS 方案代替
3、IS NULL 或IS NOT NULL操作（判斷欄位是否為空）
判斷欄位是否為空一般是不會應用索引的，因為索引是不索引空值的。
推薦方案：用其它相同功能的操作運算代替，如：a is not null 改為 a>0 或a>』』等。不允許欄位為空，而用一個預設值代替空值，如申請中狀態欄位不允許為空，預設為申請。
4、> 及 < 操作符（大於或小於操作符）
大於或小於操作符一般情況下是不用調整的，因為它有索引就會採用索引查找，但有的情況下可以對它進行優化，如一個表有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的記錄索引。
5、LIKE操作符
LIKE操作符可以應用通配符查詢，裡面的通配符組合可能達到幾乎是任意的查詢，但是如果用得不好則會產生性能上的問題，如LIKE 『%5400%』 這種查詢不會引用索引，而LIKE 『X5400%』則會引用范圍索引。
一個實際例子：用YW_YHJBQK表中營業編號後面的戶標識號可來查詢營業編號 YY_BH LIKE 『%5400%』 這個條件會產生全表掃描，如果改成YY_BH LIKE 』X5400%』 OR YY_BH LIKE 』B5400%』 則會利用YY_BH的索引進行兩個范圍的查詢，性能肯定大大提高。
6、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書寫的影響
1、同一功能同一性能不同寫法SQL的影響。
如一個SQL在A程序員寫的為 Select * from zl_yhjbqk
B程序員寫的為 Select * from dlyx.zl_yhjbqk（帶表所有者的前綴）
C程序員寫的為 Select * from DLYX.ZLYHJBQK（大寫表名）
D程序員寫的為 Select * from DLYX.ZLYHJBQK（中間多了空格）
以上四個SQL在ORACLE分析整理之後產生的結果及執行的時間是一樣的，但是從ORACLE共享內存SGA的原理，可以得出ORACLE對每個SQL 都會對其進行一次分析，並且佔用共享內存，如果將SQL的字元串及格式寫得完全相同，則ORACLE只會分析一次，共享內存也只會留下一次的分析結果，這不僅可以減少分析SQL的時間，而且可以減少共享內存重復的信息，ORACLE也可以准確統計SQL的執行頻率。
2、WHERE後面的條件順序影響
WHERE子句後面的條件順序對大數據量表的查詢會產生直接的影響。如：
Select * from zl_yhjbqk where dy_dj = '1KV以下' and xh_bz=1
Select * from zl_yhjbqk where xh_bz=1 and dy_dj = '1KV以下'
以上兩個SQL中dy_dj（電壓等級）及xh_bz（銷戶標志）兩個欄位都沒進行索引，所以執行的時候都是全表掃描，第一條SQL的dy_dj = '1KV以下'條件在記錄集內比率為99%，而xh_bz=1的比率只為0.5%，在進行第一條SQL的時候99%條記錄都進行dy_dj及xh_bz的比較，而在進行第二條SQL的時候0.5%條記錄都進行dy_dj及xh_bz的比較，以此可以得出第二條SQL的CPU佔用率明顯比第一條低。
3、查詢表順序的影響
在FROM後面的表中的列表順序會對SQL執行性能影響，在沒有索引及ORACLE沒有對表進行統計分析的情況下，ORACLE會按表出現的順序進行鏈接，由此可見表的順序不對時會產生十分耗服物器資源的數據交叉。（註：如果對表進行了統計分析，ORACLE會自動先進小表的鏈接，再進行大表的鏈接）
三、SQL語句索引的利用
1、操作符優化（同上）
2、對條件欄位的一些優化
採用函數處理的欄位不能利用索引，如：
substr(hbs_bh,1,4)=』5400』，優化處理：hbs_bh like 『5400%』
trunc(sk_rq)=trunc(sysdate)， 優化處理：sk_rq>=trunc(sysdate) and sk_rq<trunc(sysdate+1)
進行了顯式或隱式的運算的欄位不能進行索引，如：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的提示功能是比較強的功能，也是比較復雜的應用，並且提示只是給ORACLE執行的一個建議，有時如果出於成本方面的考慮ORACLE也可能不會按提示進行。根據實踐應用，一般不建議開發人員應用ORACLE提示，因為各個資料庫及伺服器性能情況不一樣，很可能一個地方性能提升了，但另一個地方卻下降了，ORACLE在SQL執行分析方面已經比較成熟，如果分析執行的路徑不對首先應在資料庫結構（主要是索引）、伺服器當前性能（共享內存、磁碟文件碎片）、資料庫對象（表、索引）統計信息是否正確這幾方面分析。
E. sql哪些操作降低效率，哪些提升效率
1. SQL優化的原則是：將一次操作需要讀取的BLOCK數減到最低,即在最短的時間達到最大的數據吞吐量。
調整不良SQL通常可以從以下幾點切入：
? 檢查不良的SQL，考慮其寫法是否還有可優化內容
? 檢查子查詢 考慮SQL子查詢是否可以用簡單連接的方式進行重新書寫
? 檢查優化索引的使用
? 考慮資料庫的優化器
2. 避免出現SELECT * FROM table 語句，要明確查出的欄位。
3. 在一個SQL語句中，如果一個where條件過濾的資料庫記錄越多，定位越准確，則該where條件越應該前移。
4. 查詢時盡可能使用索引覆蓋。即對SELECT的欄位建立復合索引，這樣查詢時只進行索引掃描，不讀取數據塊。
5. 在判斷有無符合條件的記錄時建議不要用SELECT COUNT （*）和select top 1 語句。
6. 使用內層限定原則，在拼寫SQL語句時，將查詢條件分解、分類，並盡量在SQL語句的最里層進行限定，以減少數據的處理量。
7. 應絕對避免在order by子句中使用表達式。
8. 如果需要從關聯表讀數據，關聯的表一般不要超過7個。
9. 小心使用 IN 和 OR，需要注意In集合中的數據量。建議集合中的數據不超過200個。
10. <> 用 < 、 > 代替，>用>=代替，<用<=代替，這樣可以有效的利用索引。
11. 在查詢時盡量減少對多餘數據的讀取包括多餘的列與多餘的行。
12. 對於復合索引要注意，例如在建立復合索引時列的順序是F1，F2，F3，則在where或order by子句中這些欄位出現的順序要與建立索引時的欄位順序一致，且必須包含第一列。只能是F1或F1，F2或F1，F2，F3。否則不會用到該索引。
13. 多表關聯查詢時，寫法必須遵循以下原則，這樣做有利於建立索引，提高查詢效率。格式如下select sum（table1.je） from table1 table1, table2 table2, table3 table3 where (table1的等值條件（=）) and (table1的非等值條件) and (table2與table1的關聯條件) and (table2的等值條件) and (table2的非等值條件) and (table3與table2的關聯條件) and (table3的等值條件) and (table3的非等值條件)。
注:關於多表查詢時from 後面表的出現順序對效率的影響還有待研究。
14. 子查詢問題。對於能用連接方式或者視圖方式實現的功能，不要用子查詢。例如：select name from customer where customer_id in ( select customer_id from order where money>1000)。應該用如下語句代替：select name from customer inner join order on customer.customer_id=order.customer_id where order.money>100。
15. 在WHERE 子句中，避免對列的四則運算，特別是where 條件的左邊，嚴禁使用運算與函數對列進行處理。比如有些地方 substring 可以用like代替。
16. 如果在語句中有not in（in）操作，應考慮用not exists（exists）來重寫,最好的辦法是使用外連接實現。
17. 對一個業務過程的處理，應該使事物的開始與結束之間的時間間隔越短越好，原則上做到資料庫的讀操作在前面完成，資料庫寫操作在後面完成，避免交叉。
18. 請小心不要對過多的列使用列函數和order by,group by等，謹慎使用disti軟體開發t。
19. 用union all 代替 union，資料庫執行union操作，首先先分別執行union兩端的查詢，將其放在臨時表中，然後在對其進行排序，過濾重復的記錄。
當已知的業務邏輯決定query A和query B中不會有重復記錄時，應該用union all代替union，以提高查詢效率。
數據更新的效率
1. 在一個事物中，對同一個表的多個insert語句應該集中在一起執行。
2. 在一個業務過程中，盡量的使insert,update,delete語句在業務結束前執行，以減少死鎖的可能性。
資料庫物理規劃的效率
為了避免I/O的沖突，我們在設計資料庫物理規劃時應該遵循幾條基本的原則(以ORACLE舉例)：
?? table和index分離：table和index應該分別放在不同的tablespace中。
?? Rollback Segment的分離：Rollback Segment應該放在獨立的Tablespace中。
?? System Tablespace的分離：System Tablespace中不允許放置任何用戶的object。（mssql中primary filegroup中不允許放置任何用戶的object）
?? Temp Tablesace的分離：建立單獨的Temp Tablespace，並為每個user指定default Temp Tablespace
??避免碎片：但segment中出現大量的碎片時，會導致讀數據時需要訪問的block數量的增加。對經常發生DML操作的segemeng來說，碎片是不能完全避免的。所以，我們應該將經常做DML操作的表和很少發生變化的表分離在不同的Tablespace中。
當我們遵循了以上原則後，仍然發現有I/O沖突存在，我們可以用數據分離的方法來解決。
?? 連接Table的分離：在實際應用中經常做連接查詢的Table，可以將其分離在不同的Taclespace中，以減少I/O沖突。
?? 使用分區：對數據量很大的Table和Index使用分區，放在不同的Tablespace中。
在實際的物理存儲中，建議使用RAID。日誌文件應放在單獨的磁碟中。
F. 查詢的SQL語句怎麼寫才能提高查詢效率
這是SQL語句優化的問題了。網上好多類似的文章，非常全面。
個人覺得比較常用的是：
SQL語句查詢中經常用到的欄位建索引，這樣可以非常明顯的提升查詢速度。
FROM表的順序，大表在前，小表在後，因為檢索的順序從後往前。
WHERE， WHERE A.COLUMN = B.COLUMN，把小表的欄位放在後邊（B表），大表在前。
固定值查詢的放在後邊 COLUMN = '1'這種。因為這個也是從後往前的順序。
如果有(NOT) IN (SELECT ...) 盡量避免，因為IN裡面也是一個大的查詢，使用 (NOT) EXISTS的語法代替。
還有UNION和UNION ALL，多表聯合，UNION的作用是可以去掉重復，如果多表沒有重復數據，使用UNION ALL效率也會大大提高。
G. SQL語句 優化問題，提高性能
唉。。。說的千奇百怪什麼都有，真是。。。。
下面，說說我的看法：
首先，like '%asdasd%'會造成表掃描。
其次，like 'asdasd%'可能無法滿足樓主的要求
再次，like 並不是只有查不到的時候才遍歷全表，是每次都要遍歷。
給樓主兩個建議方案，第一就是給 關鍵字 欄位建索引
例如 select * from table1 where id like '%qweqwe%'
此時如果id有索引，或者是主鍵，那麼就應該不會構成表掃描。但是有時候也有例外，有時候一樣的腳本，換換格式，效率也就不一樣，相信是優化器的作用。
第二方案，查詢沒有數據的時候慢，那麼樓主試試不要查出每條數據，用count(*)先查一下試試，如果結果為0，就不用查了。
不過不是很建議用第二方案，除非迫不得已。
還有，樓主可以用查詢分析器分析一下腳本的效率，看看什麼地方構成表掃描，改善一下即可
H. 如何進行SQL性能優化
這里分享下mysql優化的幾種方法。
1、首先在打開的軟體中，需要分別為每一個表創建 InnoDB FILE的文件。
I. SQLITE或者MYSQL在行數很多（比如5K或者1W條以上）的情況下，欄位多會降低效率么
1,首先,欄位多肯定會影響效率,但欄位的大小同樣會影響效率,
2,對於mysql來說,如果你的機器不是老古董型的話,5K-1W行,,你50個欄位,看你查詢條件的復雜度,一般也可以得到很好的速度,,如果行數到達一定級別,(500W以上),可以考慮用分區或分表的形式.
3,你上面所說的這種方式,那SQL已經完全沒有意義了,如果你的欄位確實非常多的話,可以把一些主要查詢欄位存放一個表,把次要的欄位存放一個表,查詢時可以主查主要條件,用各咱join去關聯起來.