⑴ sql優化具體指的是什麼
SQL語言，是結構化查詢語言(StructuredQueryLanguage)的簡稱。SQL語言是一種資料庫查詢和程序設計語言，用於存取數據以及查詢、更新和管理關系資料庫系統；同時也是資料庫腳本文件的擴展名。
定位有問題的語句，檢查執行計劃，檢查執行過程中優化器的統計信息，分析相關表的記錄數、索引情況改寫SQL語句、使用HINT、調整索引、表分析有些SQL語句不具備優化的可能，需要優化處理方式達到最佳執行計劃。但是最佳的執行計劃不一定是最佳的執行情況。一切以實際執行的情況為准。
⑵ 如何進行SQL性能優化
SQL Server資料庫查詢速度慢的原因有很多，常見的有以下幾種：
1、沒有索引或者沒有用到索引(這是查詢慢最常見的問題，是資料庫設計的缺陷)
2、I/O吞吐量小，形成了瓶頸效應。
3、沒有創建計算列導致查詢不優化。
4、內存不足
5、網路速度慢
6、查詢出的數據量過大（可以採用多次查詢，其他的方法降低數據量）
7、鎖或者死鎖(這也是查詢慢最常見的問題，是程序設計的缺陷)
8、sp_lock,sp_who,活動的用戶查看,原因是讀寫競爭資源。
9、返回了不必要的行和列
10、查詢語句不好，沒有優化
●可以通過以下方法來優化查詢 :
1、把數據、日誌、索引放到不同的I/O設備上，增加讀取速度，以前可以將Tempdb應放在RAID0上，SQL2000不在支持。數據量（尺寸）越大，提高I/O越重要。
2、縱向、橫向分割表，減少表的尺寸(sp_spaceuse)
3、升級硬體
4、根據查詢條件,建立索引,優化索引、優化訪問方式，限制結果集的數據量。注意填充因子要適當（最好是使用默認值0）。索引應該盡量小，使用位元組數小的列建索引好（參照索引的創建）,不要對有限的幾個值的欄位建單一索引如性別欄位。
5、提高網速。
6、擴大伺服器的內存,Windows 2000和SQL server 2000能支持4-8G的內存。
配置虛擬內存：虛擬內存大小應基於計算機上並發運行的服務進行配置。運行 Microsoft SQL Server? 2000時，可考慮將虛擬內存大小設置為計算機中安裝的物理內存的1.5倍。如果另外安裝了全文檢索功能，並打算運行Microsoft搜索服務以便執行全文索引和查詢，可考慮：將虛擬內存大小配置為至少是計算機中安裝的物理內存的3倍。將SQL Server max server memory伺服器配置選項配置為物理內存的1.5倍（虛擬內存大小設置的一半）。
7、增加伺服器CPU個數;但是必須 明白並行處理串列處理更需要資源例如內存。使用並行還是串列程是MSSQL自動評估選擇的。單個任務分解成多個任務，就可以在處理器上運行。例如耽擱查詢 的排序、連接、掃描和GROUP BY字句同時執行，SQL SERVER根據系統的負載情況決定最優的並行等級，復雜的需要消耗大量的CPU的查詢最適合並行處理。但是更新操作UPDATE,INSERT， DELETE還不能並行處理。
8、如果是使用like進行查詢的話，簡單的使用index是不行的，但是全文索引，耗空間。 like ''a%'' 使用索引 like ''%a'' 不使用索引用 like ''%a%'' 查詢時，查詢耗時和欄位值總長度成正比,所以不能用CHAR類型，而是VARCHAR。對於欄位的值很長的建全文索引。
9、DB Server 和APPLication Server 分離；OLTP和OLAP分離
10、分布式分區視圖可用於實現資料庫伺服器聯合體。
聯合體是一組分開管理的伺服器，但它們相互協作分擔系統的處理負荷。這種通過分區數據形成資料庫伺服器聯合體的機制能夠擴大一組伺服器，以支持大型的多層 Web 站點的處理需要。有關更多信息，參見設計聯合資料庫伺服器。（參照SQL幫助文件''分區視圖''）
a、在實現分區視圖之前，必須先水平分區表
b、 在創建成員表後，在每個成員伺服器上定義一個分布式分區視圖，並且每個視圖具有相同的名稱。這樣，引用分布式分區視圖名的查詢可以在任何一個成員伺服器上 運行。系統操作如同每個成員伺服器上都有一個原始表的復本一樣，但其實每個伺服器上只有一個成員表和一個分布式分區視圖。數據的位置對應用程序是透明的。
11、重建索引 DBCC REINDEX ,DBCC INDEXDEFRAG,收縮數據和日誌 DBCC SHRINKDB,DBCC SHRINKFILE. 設置自動收縮日誌.對於大的資料庫不要設置資料庫自動增長，它會降低伺服器的性能。
在T-sql的寫法上有很大的講究，下面列出常見的要點：首先，DBMS處理查詢計劃的過程是這樣的：
1、 查詢語句的詞法、語法檢查
2、 將語句提交給DBMS的查詢優化器
3、 優化器做代數優化和存取路徑的優化
4、 由預編譯模塊生成查詢規劃
5、 然後在合適的時間提交給系統處理執行
6、 最後將執行結果返回給用戶。
其次，看一下SQL SERVER的數據存放的結構：一個頁面的大小為8K(8060)位元組，8個頁面為一個盤區，按照B樹存放。
⑶ 怎樣進行sql資料庫的優化
1、資料庫空間是個概述，在sqlserver里，使用語句 exec sp_spaceused 'TableName' 這個語句來查。
⑷ 如何進行SQL優化
第一。性能的，原來串列執行的，改成並行執行
第二，性能的，少用函數計算，可以降低復雜度
⑸ 如何進行SQL優化請寫出三種以上的方法,並分別做出解釋說明
摘要 1:mysql所在伺服器內核 優化；此優化可由系統運維人員完成
⑹ 如何優化SQL語句
一、問題的提出
在應用系統開發初期，由於開發資料庫數據比較少，對於查詢SQL語句，復雜視圖的的編寫等體會不出SQL語句各種寫法的性能優劣，但是如果將應用系統提交實際應用後，隨著資料庫中數據的增加，系統的響應速度就成為目前系統需要解決的最主要的問題之一。系統優化中一個很重要的方面就是SQL語句的優化。對於海量數據，劣質SQL語句和優質SQL語句之間的速度差別可以達到上百倍，可見對於一個系統不是簡單地能實現其功能就可，而是要寫出高質量的SQL語句，提高系統的可用性。
在多數情況下，Oracle使用索引來更快地遍歷表，優化器主要根據定義的索引來提高性能。但是，如果在SQL語句的where子句中寫的SQL代碼不合理，就會造成優化器刪去索引而使用全表掃描，一般就這種SQL語句就是所謂的劣質SQL語句。在編寫SQL語句時我們應清楚優化器根據何種原則來刪除索引，這有助於寫出高性能的SQL語句。
二、SQL語句編寫注意問題
下面就某些SQL語句的where子句編寫中需要注意的問題作詳細介紹。在這些where子句中，即使某些列存在索引，但是由於編寫了劣質的SQL，系統在運行該SQL語句時也不能使用該索引，而同樣使用全表掃描，這就造成了響應速度的極大降低。
1.
IS
NULL
與
IS
NOT
NULL
不能用null作索引，任何包含null值的列都將不會被包含在索引中。即使索引有多列這樣的情況下，只要這些列中有一列含有null，該列就會從索引中排除。也就是說如果某列存在空值，即使對該列建索引也不會提高性能。
任何在where子句中使用is
null或is
not
null的語句優化器是不允許使用索引的。
2.
聯接列
對於有聯接的列，即使最後的聯接值為一個靜態值，優化器是不會使用索引的。我們一起來看一個例子，假定有一個職工表(employee)，對於一個職工的姓和名分成兩列存放(FIRST_NAME和LAST_NAME)，現在要查詢一個叫比爾.柯林頓(Bill
Cliton)的職工。
下面是一個採用聯接查詢的SQL語句，
select
*
from
employss
where
first_name||''||last_name
='Beill
Cliton';
上面這條語句完全可以查詢出是否有Bill
Cliton這個員工，但是這里需要注意，系統優化器對基於last_name創建的索引沒有使用。
當採用下面這種SQL語句的編寫，Oracle系統就可以採用基於last_name創建的索引。
***
where
first_name
='Beill'
and
last_name
='Cliton';
.
帶通配符(%)的like語句
同樣以上面的例子來看這種情況。目前的需求是這樣的，要求在職工表中查詢名字中包含cliton的人。可以採用如下的查詢SQL語句:
select
*
from
employee
where
last_name
like
'%cliton%';
這里由於通配符(%)在搜尋詞首出現，所以Oracle系統不使用last_name的索引。在很多情況下可能無法避免這種情況，但是一定要心中有底，通配符如此使用會降低查詢速度。然而當通配符出現在字元串其他位置時，優化器就能利用索引。在下面的查詢中索引得到了使用:
select
*
from
employee
where
last_name
like
'c%';
4.
Order
by語句
ORDER
BY語句決定了Oracle如何將返回的查詢結果排序。Order
by語句對要排序的列沒有什麼特別的限制，也可以將函數加入列中(象聯接或者附加等)。任何在Order
by語句的非索引項或者有計算表達式都將降低查詢速度。
仔細檢查order
by語句以找出非索引項或者表達式，它們會降低性能。解決這個問題的辦法就是重寫order
by語句以使用索引，也可以為所使用的列建立另外一個索引，同時應絕對避免在order
by子句中使用表達式。
5.
NOT
我們在查詢時經常在where子句使用一些邏輯表達式，如大於、小於、等於以及不等於等等，也可以使用and(與)、or(或)以及not(非)。NOT可用來對任何邏輯運算符號取反。下面是一個NOT子句的例子:
...
where
not
(status
='VALID')
如果要使用NOT，則應在取反的短語前面加上括弧，並在短語前面加上NOT運算符。NOT運算符包含在另外一個邏輯運算符中，這就是不等於(<>)運算符。換句話說，即使不在查詢where子句中顯式地加入NOT詞，NOT仍在運算符中，見下例:
...
where
status
<>'INVALID';
對這個查詢，可以改寫為不使用NOT:
select
*
from
employee
where
salary<3000
or
salary>3000;
雖然這兩種查詢的結果一樣，但是第二種查詢方案會比第一種查詢方案更快些。第二種查詢允許Oracle對salary列使用索引，而第一種查詢則不能使用索引。
雖然這兩種查詢的結果一樣，但是第二種查詢方案會比第一種查詢方案更快些。第二種查詢允許Oracle對salary列使用索引，而第一種查詢則不能使用索引。
⑺ SQL Server優化如何通過3個階段來完成 (1)
1.查詢分析 在查詢分析階段，SQL Server優化器查看每一個由正規查詢樹代表的子句，並判斷它是否能被優化。SQL Server優化一般會盡量優化那些限制掃描的子句。例如，搜索和/或合並子句。但是不是所有合法的SQL語法都可以分成可優化的子句，如含有SQL不等關系符「<>」的子句。 因為「<>」是1個排斥性的操作符，而不是1個包括性的操作符，所在掃描整個表之前無法確定子句的選擇范圍會有多大。當1個關系型查詢中含有不可SQL Server優化的子句時，執行計劃用表掃描來訪問查詢的這個部分，對於查詢樹中可優化的SQL Server子句，則由優化器執行索引選擇。 2.索引選擇 對於每個可優化的子句，優化器都查看資料庫系統表，以確定是否有相關的索引能用於訪問數據。只有當索引中的列的1個前綴與查詢子句中的列完全匹配時，這個索引才被認為是有用的。因為索引是根據列的順序構造的，所以要求匹配是精確的匹配。 所以在設計過程中，要根據查詢設計准則仔細檢查所有的查詢，以查詢的優化特點為基礎設計索引。 (1)比較窄的索引具有比較高的效率。對於比較窄的索引來說，每頁上能存放較多的索引行，而且索引的級別也較少。所以，緩存中能放置更多的索引頁，這樣也減少了I/O操作。 (2)SQL Server優化器能分析大量的索引和合並可能性。所以與較少的寬索引相比，較多的窄索引能向優化器提供更多的選擇。但是不要保留不必要的索引，因為它們將增加存儲和維護的開支。對於復合索引、組合索引或多列索引，SQL Server優化器只保留最重要的列的分布統計信息，這樣，索引的第1列應該有很大的選擇性。 (3)表上的索引過多會影響UPDATE、INSERT和DELETE的性能，因為所有的索引都必須做相應的調整。另外，所有的分頁操作都被記錄在日誌中，這也會增加I/O操作。 (4)對1個經常被更新的列建立索引，會嚴重影響性能。 (5)由於存儲開支和I/O操作方面的原因，較小的自組索引比較大的索引性能更好一些。但它的缺點是要維護自組的列。 (6)盡量分析出每一個重要查詢的使用頻度，這樣可以找出使用最多的索引，然後可以先對這些索引進行適當的優化。 (7)查詢中的WHERE子句中的任何列都很可能是個索引列，因為優化器重點處理這個子句。 (8)對小於1個范圍的小型表進行索引是不劃算的，因為對於小表來說表掃描往往更快而且費用低。 (9)與「ORDER BY」或「GROUP BY」一起使用的列一般適於做分族索引。如果「ORDER BY」命令中用到的列上有分簇索引，那麼就不會再生成1個工作表了，因為行已經排序了。「GROUP BY」命令則一定產生1個工作表。 (10)分簇索引不應該構造在經常變化的列上，因為這會引起整行的移動。
⑻ 資料庫怎麼優化sql怎麼優化
1 避免無計劃的全表掃描
如下情況進行全表掃描：
- 該表無索引
- 對返回的行無任何限制條件（無Where子句）
- 對於索引主列（索引的第一列）無限制條件
- 對索引主列的條件含在表達式中
- 對索引主列的限制條件是is (not) null或!=
- 對索引主列的限制條件是like操作且值是一個bind variable或%打頭的值
2 只使用選擇性索引
索引的選擇性是指索引列中不同值得數目和標志中記錄數的比，選擇性最好的是非空列的唯一索引為1.0。
復合索引中列的次序的問題：
1 在限定條件里最頻繁使用的列應該是主列
2 最具有選擇性的列（即最清晰的列）應該是主列
如果1和2 不一致，可以考慮建立多個索引。
在復合索引和多個單個索引中作選擇：
考慮選擇性 考慮讀取索引的次數 考慮AND-EQUAL操作
3 管理多表連接（Nested Loops, Merge Joins和Hash Joins） 優化聯接操作
Merge Joins是集合操作 Nested Loops和Hash Joins是記錄操作返回第一批記錄迅速
Merge Joins的操作適用於批處理操作，巨大表 和遠程查詢
1全表掃描 --〉 2排序 --〉3比較和合並 性能開銷主要在前兩步
適用全表掃描的情形，都適用Merge Joins操作（比Nested Loops有效）。
改善1的效率： 優化I/O， 提高使用ORACLE多塊讀的能力， 使用並行查詢的選項
改善1的效率：提高Sort_Area_Size的值， 使用Sort Direct Writes，為臨時段提供專用表空間
4 管理包含視圖的SQL語句
優化器執行包含視圖的SQL語句有兩種方法：
- 先執行視圖，完成全部的結果集，然後用其餘的查詢條件作過濾器執行查詢
- 將視圖文本集成到查詢里去
含有group by子句的視圖不能被集成到一個大的查詢中去。
在視圖中使用union，不阻止視圖的SQL集成到查詢的語法中去。
5 優化子查詢
6 使用復合Keys/Star查詢
7 恰當地索引Connect By操作
8 限制對遠程表的訪問
9 管理非常巨大的表的訪問
- 管理數據接近(proximity) 記錄在表中的存放按對表的范圍掃描中最長使用的列排序 按次序存儲數據有助於范圍掃描，尤其是對大表。
- 避免沒有幫助的索引掃描 當返回的數據集合較大時，使用索引對SGA的數據塊緩存佔用較大，影響其他用戶；全表掃描還能從ORACLE的多塊讀取機制和「一致性獲取/每塊」特性中受益。
- 創建充分索引的表 使訪問索引能夠讀取較全面的數據 建立僅主列不同的多個索引
- 創建hash簇
- 創建分割表和視圖
- 使用並行選項
10 使用Union All 而不是Union
UNION ALL操作不包括Sort Unique操作，第一行檢索的響應速度快，多數情況下不用臨時段完成操作，
UNION ALL建立的視圖用在查詢里可以集成到查詢的語法中去，提高效率
11 避免在SQL里使用PL/SQL功能調用
12 綁定變數(Bind Variable)的使用管理
使用Bind Variable和Execute using方式
將like :name ||』%』 改寫成 between :name and :name || char(225), 已避免進行全表掃描，而是使用索引。
13 回訪優化進程
數據變化後，重新考察優化情況
⑼ sql語句優化怎麼做的，建索引的時候要考慮什麼
1、表的主鍵、外鍵必須有索引；
2、數據量超過300的表應該有索引；
3、經常與其他表進行連接的表，在連接欄位上應該建立索引；
4、經常出現在Where子句中的欄位，特別是大表的欄位，應該建立索引；
5、索引應該建在選擇性高的欄位上；
6、索引應該建在小欄位上，對於大的文本欄位甚至超長欄位，不要建索引；
7、復合索引的建立需要進行仔細分析；盡量考慮用單欄位索引代替：
A、正確選擇復合索引中的主列欄位，一般是選擇性較好的欄位；
B、復合索引的幾個欄位是否經常同時以AND方式出現在Where子句中？單欄位查詢是否極少甚至沒有？如果是，則可以建立復合索引；否則考慮單欄位索引；
C、如果復合索引中包含的欄位經常單獨出現在Where子句中，則分解為多個單欄位索引；
D、如果復合索引所包含的欄位超過3個，那麼仔細考慮其必要性，考慮減少復合的欄位；
E、如果既有單欄位索引，又有這幾個欄位上的復合索引，一般可以刪除復合索引；
8、頻繁進行數據操作的表，不要建立太多的索引；
9、刪除無用的索引，避免對執行計劃造成負面影響；
以上是一些普遍的建立索引時的判斷依據。一言以蔽之，索引的建立必須慎重，對每個索引的必要性都應該經過仔細分析，要有建立的依據。因為太多的索引與不充分、不正確的索引對性能都毫無益處：在表上建立的每個索引都會增加存儲開銷，索引對於插入、刪除、更新操作也會增加處理上的開銷。另外，過多的復合索引，在有單欄位索引的情況下，一般都是沒有存在價值的；相反，還會降低數據增加刪除時的性能，特別是對頻繁更新的表來說，負面影響更大。
⑽ 列舉sql優化有哪些方式方法 博客園
sql優化的方式有：
1、選擇最有效率的表名順序(只在基於規則的優化器中有效)：
ORACLE 的解析器按照從右到左的順序處理FROM子句中的表名，FROM子句中寫在最後的表(基礎表 driving table)將被最先處理，在FROM子句中包含多個表的情況下,你必須選擇記錄條數最少的表作為基礎表。如果有3個以上的表連接查詢, 那就需要選擇交叉表(intersection table)作為基礎表, 交叉表是指那個被其他表所引用的表。
2、WHERE子句中的連接順序：
ORACLE採用自下而上的順序解析WHERE子句,根據這個原理,表之間的連接必須寫在其他WHERE條件之前, 那些可以過濾掉最大數量記錄的條件必須寫在WHERE子句的末尾。
3、SELECT子句中避免使用 『 * 『：
ORACLE在解析的過程中, 會將'*' 依次轉換成所有的列名, 這個工作是通過查詢數據字典完成的, 這意味著將耗費更多的時間 。
4、 減少訪問資料庫的次數：
ORACLE在內部執行了許多工作: 解析SQL語句, 估算索引的利用率, 綁定變數 , 讀數據塊等。
5、 在SQL*Plus , SQL*Forms和Pro*C中重新設置ARRAYSIZE參數, 可以增加每次資料庫訪問的檢索數據量 ,建議值為200 。
6、 使用DECODE函數來減少處理時間：
使用DECODE函數可以避免重復掃描相同記錄或重復連接相同的表。
7、整合簡單,無關聯的資料庫訪問：
如果你有幾個簡單的資料庫查詢語句,你可以把它們整合到一個查詢中(即使它們之間沒有關系)。