1. 請教一個sql查詢排序及優化的問題！
樓主這個功能需要進行模糊查詢，使用like '%內容%'的形式是沒法利用索引來提高性能的，因此，不用考慮建索引的事情，而且也沒有比較好的辦法來對這個事情進行優化，可能需要從設計的角度考慮設計為這種類型是否合適？如果必須這樣，那性能慢是很正常的，不過你可以考慮一些對表中數據量的總數進行控制來提高性能，比如：對不必要的數據進行刪除，或者備份到其它表中等等
對於whs_love的回答，sql語句本身沒有什麼問題，這樣寫是可以的。
2. Mysql trace分析SQL優化器
explain 可以查看 SQL 執行計劃，但是無法知道它為什麼做這個決策，如果想確定多種索引方案之間是如何選擇的或者排序時選擇的是哪種排序模式。從 MySQL 5.6 開始，可以使用 trace 查看優化器如何選擇執行計劃。通過trace，能夠進一步了解為什麼優化器選擇A執行計劃而不是選擇B執行計劃，或者知道某個排序使用的排序模式，幫助我們更好地理解優化器行為。
分析trace中的執行計劃。可以有效分析建的索引為什麼沒有走。查看優化器如何選擇執行計劃，獲取每個可能的索引選擇的代價。
TRACE 欄位中整個文本大致分為三個過程。
准備階段：對應文本中的 join_preparation
優化階段：對應文本中的 join_optimization
執行階段：對應文本中的 join_execution
使用時，重點關注優化階段和執行階段。
索引欄位會作用在查詢和排序時，有排序欄位時考慮跟查詢一塊建立組合索引
3. 什麼是SQL的查詢優化,舉例說明
1 使用SET NOCOUNT ON 選項：
預設地，每次執行SQL語句時，一個消息會從服務端發給客戶端以顯示SQL語句影響的行數。這些信息對客戶端來說很少有用。通過關閉這個預設值，你能減少在服務端和客戶端的網路流量，幫助全面提升伺服器和應用程序的性能。為了關閉存儲過程級的這個特點，在每個存儲過程的開頭
包含「SET NOCOUNT ON」語句。
2 正確使用UNION和UNION ALL：
許多人沒完全理解UNION和UNION SELECT是怎樣工作的，因此，結果浪費了大量不必要的SQLServer資源。當使用UNION時，它相當於在結果集上執行SELECT DISTINCT。換句話說，UNION將聯合兩個相類似的記錄集，然後搜索重復的記錄並排除。如果這是你的目的，那麼使用UNION是正
確的。但如果你使用UNION聯合的兩個記錄集沒有重復記錄，那麼使用UNION會浪費資源，因為它要尋找重復記錄，即使你確定它們不存在。
所以如果你知道你要聯合的記錄集里沒有重復，那麼你要使用UNION ALL，而不是UNION。UNION ALL聯合記錄集，但不搜索重復記錄，這樣減少SQLServer資源的使用，從而提升性能。
3 盡量不用SELECT * ：
絕大多數情況下，不要用 * 來代替查詢返回的欄位列表，用 * 的好處是代碼量少、就算是表結構或視圖的列發生變化，編寫的查詢SQL語句也不用變，都返回所有的欄位。但資料庫伺服器在解析時，如果碰到 *，則會先分析表的結構，然後把表的所有欄位名再羅列出來。這就增加了
分析的時間。
4 慎用SELECT DISTINCT：
DISTINCT子句僅在特定功能的時候使用，即從記錄集中排除重復記錄的時候。這是因為DISTINCT子句先獲取結果集然後去重，這樣增加SQLServer有用資源的使用。當然，如果你需要去做，那就只有去做了。
當如果你知道SELECT語句將從不返回重復記錄，那麼使用DISTINCT語句對SQLServer資源不必要的浪費。
5 少用游標：
任何一種游標都會降低SQLServer性能。有些情況不能避免，大多數情況可以避免。所以如果你的應用程序目前正在使用TSQL游標，看看這些代碼是否能夠重寫以避免它們。如果你需要一行一行的執行操作，考慮下邊這些選項中的一個或多個來代替游標的使用：
使用臨時表
使用WHILE循環
使用派生表
使用相關子查詢
使用CASE語句
使用多個查詢
上面每一個都能取代游標並且執行更快。 如果你不能避免使用游標，至少試著提高它們的速度，找出加速游標的方法。
6 選擇最有效率的表名順序：
SQLSERVER的解析器按照從右到左的順序處理FROM子句中的表名，因此FROM子句中寫在最後的表（基礎表driving table）將被最先處理，在FROM子句中包含多個表的情況下，必須選擇記錄條數最少的表作為基礎表，當SQLSERVER處理多個表時，會運用排序及合並的方式連接它們。首先
，掃描第一個表（FROM子句中最後的那個表)並對記錄進行排序；然後掃描第二個表（FROM子句中最後第二個表)；最後將所有從第二個表中檢索出的記錄與第一個表中合適記錄進行合並。
例如: 表 TAB1有 16384 條記錄，表 TAB2 有5條記錄，選擇TAB2作為基礎表 (最好的方法)：
select count(*) from TAB1 a, TAB2 b
選擇TAB1作為基礎表 (不佳的方法)：
select count(*) from TAB2 a, TAB1 b
如果有3個以上的表連接查詢，那就需要選擇交叉表（intersection table）作為基礎表，交叉表是指那個被其他表所引用的表。
7 使用表的別名(Alias)：
當在SQL語句中連接多個表時，請使用表的別名並把別名前綴於每個Column上，這樣可以減少解析的時間並減少那些由Column歧義引起的語法錯誤。
8 SARG你的WHERE條件：
ARGE來源於"Search Argument"（搜索參數）的首字母拼成的"SARG"，它是指WHERE子句里，列和常量的比較。如果WHERE子句是sargable（可SARG的），這意味著它能利用索引加速查詢的完成。如果WHERE子句不是可SARG的，這意味著WHERE子句不能利用索引（或至少部分不能利用），
執行的是全表或索引掃描，這會引起查詢的性能下降。
在WHERE子句里不可SARG的搜索條件如"IS NULL", "<>", "!=", "!>", "!<", "NOT", "NOT EXISTS", "NOT IN", "NOT LIKE"和"LIKE '%500'"，通常（但不總是）會阻止查詢優化器使用索引執行搜索。另外在列上使用包括函數的表達式、兩邊都使用相同列的表達式、或和一個列（不是常
量）比較的表達式，都是不可SARG的。
並不是每一個不可SARG的WHERE子句都註定要全表掃描。如果WHERE子句包括兩個可SARG和一個不可SARG的子句，那麼至少可SARG的子句能使用索引（如果存在的話）幫助快速訪問數據。
大多數情況下，如果表上有包括查詢里所有SELECT、JOIN、WHERE子句用到的列的覆蓋索引，那麼覆蓋索引能夠代替全表掃描去返回查詢的數據，即使它有不可SARG的WHERE子句。但記住覆蓋索引尤其自身的缺陷，如此經常產生寬索引會增加讀磁碟I/O。某些情況下，可以把不可SARG的WHER
E子句重寫成可SARG的子句。例如：
WHERE SUBSTRING(firstname,1,1) = 'm'
可以寫成：
WHERE firstname like 'm%'
這兩個WHERE子句有相同的結果，但第一個是不可SARG的（因為使用了函數）將運行得慢些，而第二個是可SARG的，將運行得快些。
如果你不知道特定的WHERE子句是不是可SARG的，在查詢分析器里檢查查詢執行計劃。這樣做，你能很快的知道查詢是使用了索引還是全表掃描來返回的數據。仔細分析，許多不可SARG的查詢能寫成可SARG的查詢。下面分幾點講解WHERE條件的SARG。
8.1 WHERE子句中的連接順序
SQLSERVER採用自下而上的順序解析WHERE子句，根據這個原理，表之間的連接必須寫在其他WHERE條件之前，那些可以過濾掉最大數量記錄的條件必須寫在WHERE子句的末尾。例如：
(低效)
SELECT * FROM EMP E
WHERE SAL > 50000
AND JOB = 『MANAGER』
AND 25 < (SELECT COUNT(*) FROM EMP WHERE MGR=E.EMPNO)
(高效)
SELECT * FROM EMP E
WHERE 25 < (SELECT COUNT(*) FROM EMP WHERE MGR=E.EMPNO)
AND SAL > 50000
AND JOB = 『MANAGER』
8.2 避免困難的正規表達式：
MATCHES和LIKE關鍵字支持通配符匹配，技術上叫正規表達式。但這種匹配特別耗費時間。例如：
SELECT * FROM customer WHERE zipcode LIKE "98_ _ _"
即使在zipcode欄位上建立了索引，在這種情況下也還是採用順序掃描的方式。如果把語句改為SELECT * FROM customer WHERE zipcode >="98000"，在執行查詢時就會利用索引來查詢，顯然會大大提高速度。
另外，還要避免非開始的子串。例如語句：
SELECT * FROM customer WHERE zipcode[2，3] >"80"
在where子句中採用了非開始子串，因而這個語句也不會使用索引。
8.3 避免對大型錶行數據的順序存取：
在嵌套查詢中，對表的順序存取對查詢效率可能產生致命的影響。比如採用順序存取策略，一個嵌套3層的查詢，如果每層都查詢1000行，那麼這個查詢就要查詢10億行數據。避免這種情況的主要方法就是對連接的列進行索引。例如，兩個表：學生表（學號、姓名、年齡……）和選課表（
學號、課程號、成績）。如果兩個表要做連接，就要在「學號」這個連接欄位上建立索引。
還可以使用並集來避免順序存取。盡管在所有的檢查列上都有索引，但某些形式的where子句強迫優化器使用順序存取。下面的查詢將強迫對orders表執行順序操作：
SELECT * FROM orders WHERE (customer_num=104 AND order_num>1001) OR order_num=1008
雖然在customer_num和order_num上建有索引，但是在上面的語句中優化器還是使用順序存取路徑掃描整個表。因為這個語句要檢索的是分離的行的集合，所以應該改為如下語句：
SELECT * FROM orders WHERE customer_num=104 AND order_num>1001
UNION ALL
SELECT * FROM orders WHERE order_num=1008
這樣就能利用索引路徑處理查詢。
8.4 EXISTS和IN的使用：
在許多基於基礎表的查詢中，為了滿足一個條件，往往需要對另一個表進行聯接。 在這種情況下，使用EXISTS(或NOT EXISTS)通常將提高查詢的效率。在子查詢中，NOT IN子句將執行一個內部的排序和合並。無論在哪種情況下，NOT IN都是最低效的，因為它對子查詢中的表執行
了一個全表遍歷。為了避免使用NOT IN，我們可以把它改寫成外連接(Outer Joins)或NOT EXISTS。
8.5 避免在索引列上使用IS NULL和IS NOT NULL：
避免在索引中使用任何可以為空的列，SQLSERVER將無法使用該索引。對於單列索引，如果列包含空值，索引中將不存在此記錄；對於復合索引，如果每個列都為空，索引中同樣不存在此記錄。如果至少有一個列不為空，則記錄存在於索引中。
如果唯一性索引建立在表的A列和B列上，並且表中存在一條記錄的A,B值為(123,null)，SQLSERVER將不接受下一條具有相同A,B值（123,null）的記錄插入。
如果所有的索引列都為空，SQLSERVER將認為整個鍵值為空，而空不可能等於空，因此你可以插入1000條具有相同鍵值的記錄，當然它們都是空！因為空值不存在於索引列中，所以WHERE子句中對索引列進行空值比較將使SQLSERVER停用該索引。下面的代碼將會很低效（索引失效）：
SELECT … FROM DEPARTMENT WHERE DEPT_CODE IS NOT NULL
8.6 避免在索引列上使用計算：
WHERE子句中，如果索引列是函數的一部分，優化器將不使用索引而使用全表掃描。 例如下面的語句低效 ：
SELECT … FROM DEPT WHERE SAL * 12 > 25000
而下面的語句將是高效的：
SELECT … FROM DEPT WHERE SAL > 25000/12
請務必注意，查詢中不要對索引列進行處理，如：TRIM，substring，convert等等操作。
8.7 用WHERE子句替換HAVING子句：
避免使用HAVING子句，HAVING只會在檢索出所有記錄之後才對結果集進行過濾，這個處理需要排序、統計等操作。如果能通過WHERE子句限制記錄的數目，那就能減少這方面的開銷。
9 避免或簡化排序：
應當簡化或避免對大型表進行重復的排序。當能夠利用索引自動以適當的次序產生輸出時，優化器就避免了排序的步驟。以下是一些影響因素：
l 索引中不包括一個或幾個待排序的列；
l group by或order by子句中列的次序與索引的次序不一樣；
l 排序的列來自不同的表。
為了避免不必要的排序，就要正確地增建索引，合理地合並資料庫表（盡管有時可能影響表的規范化，但相對於效率的提高是值得的）。如果排序不可避免，那麼應當試圖簡化它，如縮小排序的列的范圍等。
10 臨時表的使用：
臨時表有很多特殊的用途，象用來替代游標，不過它們仍能引起性能問題，如果這個問題能消除，SQLServer將執行得更快。在永久表和臨時表的數據行相同的條件下，使用臨時表沒有永久錶快。但有時還必須得使用臨時表，如先從存儲大量數據的永久表中提取符全條件的存放到臨時
表，然後在臨時表上執行操作。如果是直接在存儲大量數據的永久表上執行操作（如：統計、循環等），其性能將大打折扣。所以，使不使用臨時表，何時使用臨時表，需要具體情況決定。
11 是否使用視圖：
視圖最大的用途是處理安全相關的問題，而不是一些懶惰的開發人員用來存儲經常使用的查詢的方法。例如，如果你需要允許用戶訪問特定SQLServer的數據，那麼你也許可以考慮為用戶（或組）創建一個視圖，然後給用戶訪問視圖而不是基表的許可權。另一方面，在應用程序里，從視圖選
擇數據沒有好的理由，相反，繞過視圖直接從需要的表裡獲取數據。原因是許多視圖（當然不是全部）返回比SELECT語句所需更多的數據，增加不必要的開銷。
例如，假定有一個視圖從兩個連接表裡返回10列。你想要從視圖里使用SELECT語句返回其中7列。實際上發生的情況是基於視圖的查詢先運行，返回數據，然後你的查詢針對這些數據運行。既然你僅需要7列，而不是視圖返回的10列，更多不必要的數據被返回。浪費SQLServer的資源。
長久以來，大家在爭論是查詢視圖速度快還是直接查詢快，本人也不敢輕易下結論，因此作了多次試驗，其結果是：基於視圖查詢，性能確實不會比直接寫查詢語句快，對於簡單的查詢，最多是在同一水平上。
當然，上面的測試是在沒有為視圖創建索引的情況下，SQLServer2000以上可以為視圖創建索引，視圖索引與表的索引在作用方式上非常相似。與表一樣，視圖可以有一個集簇索引（clustered index）和多個非集簇索引。創建視圖索引後能夠提高視圖的性能。
如果視圖不包含索引，則資料庫中不保存視圖返回的結果集。有的時候，我們可能要創建涉及大量記錄或必須進行復雜計算的視圖，比如要進行聚合分組處理或多重連接操作。如果每次引用這些視圖的時候讓sql server重新生成結果集，資料庫開銷將非常大。
12 讓事務盡可能的短：
保持TSQL事務盡可能的短。這會幫助減少鎖（所有類型的鎖）的數量，有助於全面提升SQLServer的性能。如果有經驗，你也許要將長事務分成更小的事務組。
13 用存儲過程代替直接寫查詢語句：
存儲過程為開發人員提供了很多好處，包括：
n 減少網路流量和響應時間，提升應用程序性能。例如，通過網路發送一個存儲過程調用，而不是發送500行的TSQL將更快，資源使用更少。當每次執行SQL時，都會執行解析SQL語句、估算索引的利用率、綁定變數、讀數據塊等等工作。
n 存儲過程執行計劃能夠重用，駐留在SQLServer內存的緩存里，減少伺服器開銷。
n 客戶端執行請求更有效率。例如，如果應用程序需要插入大量的二進制值到一個image數據列而不使用存儲過程，它必須轉化二進制為字元串（大小會增加一倍），然後發送給SQLServer。當SQLServer接收到後，它必須把字元串值轉回二進制格式。大量的浪費開銷。存儲過程能
消除這個問題通過將應用程序傳給SQLServer的二進制格式作為參數，從而減少開銷提升性能。
n 存儲過程幫助提供代碼重用。雖然這些不直接提升應用程序的性能，通過減少代碼量和減少調試時間來提升開發人員的效率。
n 存儲過程能封裝邏輯。你能夠改變存儲過程代碼而不影響客戶端（假定你保持參數相同也不移除任何結果集的列）。這節約開發人員的時間。
n 存儲過程為你的數據提供更好的安全性。如果你僅使用存儲過程，你可以移除直接對表的SELECT、INSERT、UPDATE和DELETE許可權從而強迫開發人員使用存儲過程訪問數據。這會節約DBA的時間。
n 作為首要的常規，所有的TSQL代碼都應該通過存儲過程調用。
13.1 存儲過程名不要以 sp_ 開頭：
對這一準則，可能很多人會感覺納悶，是的，我開始也納悶過。如果創建的存儲過程不是運行在Master資料庫里，不要使用以sp_為前綴的名稱。這個特別的前綴是為系統存儲過程保留的。盡管使用這個前綴不會禁止用戶定義的存儲過程的運行，但會稍微降低一些執行效率。這是因為
SQLServer在執行以sp_為前綴的任何一個存儲過程時預設地首先試圖在Master資料庫里尋找，盡管那兒沒有，這就浪費了尋找存儲過程的時間。如果SQLServer在Master資料庫里不能找到存儲過程，那麼接下來會將存儲過程的擁有者作為DBO去解析。如果存儲過程在目前的資料庫里，那麼
它會執行。為了避免不必要的延遲，不要用前綴為sp_命名你的任何一個存儲過程。
13.2 存儲過程的擁有者要相同：
為了最好的性能，同一個存儲過程里調用的所有對象的擁有者都應該相同，DBO更適宜。如果不是那樣，即對象名相同而擁有者不同，那麼SQLServer必須執行名稱判斷。當發生這樣的情形時，SQLServer不能使用存儲過程里在內存里的執行計劃，相反，它必須重新編譯存儲過程，從而
影響性能。當從應用程序里調用存儲過程時，使用分隔符名稱來調用也是重要的。如：
EXEC dbo.myProcere
代替：
EXEC myProcere
這樣做有兩個原因，其中一個和性能有關。首先，使用完全有分隔符的名稱有助於消除那些和你要運行的存儲過程有潛在的混淆，有助於禁止BUG和潛在的問題。但更重要的是，這樣做SQLServer能更直接的訪問存儲過程執行計劃，而不是輪流訪問，從而加速了存儲過程的性能。當然性能
提升很小，但如果你的伺服器每小時要運行成千上萬或更多的存儲過程，這些節約的小段時間加起來就很可觀了。
14 完整性使用下的約束和觸發器：
資料庫里不要執行多餘的完整性特點。例如，如果你正使用主鍵和外鍵約束來強迫引用完整性，則不要添加觸發器來實現相同的功能而增加不必要的開銷。同樣既使用約束又使用默認值或既使用約束又使用規則也會執行多餘的工作。
15 在SQL中捕捉異常：
這一條准則應該不能算是優化方面的，只是編寫要求。現在SQLServer2005中，新增了BEGIN TRY…END TRY和 BEGIN CATCH…END CATCH二個成對語句，用於捕捉運行時出現的異常。在Oracle中，可用 BEGIN…EXCEPTION…END 語句捕捉異常。
把SQL代碼塊中加入捕捉異常的語句內，有二個好處：一是可以在SQL語句內部得到異常並作錯誤處理，如在錯誤代碼塊內返回自定義錯誤信息、ROLBACK等。這樣可減少應用程序捕捉異常帶來的資源開銷；另外一個好處就是可以防止死鎖情況的發生，當出現死鎖時，SQLServer2005會拋出
異常，我們就可捕捉到。
下面列出一些索引的概念，有助於設計表結構和編寫SQL語句：
按照存儲規則來分：
l 聚集索引：該索引中鍵值的邏輯順序決定了表中相應行的物理順序。因此一個表只能包含一個聚集索引，但該索引可以包含多個列（組合索引）。檢索效率比普通索引高，但對數據新增/修改/刪除的影響比較大。
l 非聚集索引：與聚集索引相對，不影響表中的數據存儲順序，檢索效率比聚集索引低，對數據新增/修改/刪除的影響很少。
按照維護與管理的角度來分：
l 唯一索引：惟一索引可以確保索引列不包含重復的值，可以用多個列，但是索引可以確保索引列中每個值組合都是唯一的。
l 主鍵索引：在資料庫關系圖中為表定義一個主鍵將自動創建主鍵索引，主鍵索引是唯一索引的特殊類型。主鍵索引要求主鍵中的每個值是唯一的。當在查詢中使用主鍵索引時，它還允許快速訪問數據。
l 普通索引：由關鍵字KEY或INDEX定義的索引，唯一任務是加快對數據的訪問速度。因此，應該只為那些最經常出現在查詢條件或排序條件中的數據列創建索引。只要有可能，就應該選擇一個數據最整齊、最緊湊的數據列(如整數類型的數據列)來創建索引。允許有重復的列存在
。
l 復合索引：如果在兩上以上的列上創建的索引，則稱為復合索引。
4. 怎樣進行sql資料庫的優化
1、資料庫空間是個概述，在sqlserver里，使用語句 exec sp_spaceused 'TableName' 這個語句來查。
5. 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執行分析方面已經比較成熟，如果分析執行的路徑不對首先應在資料庫結構（主要是索引）、伺服器當前性能（共享內存、磁碟文件碎片）、資料庫對象（表、索引）統計信息是否正確這幾方面分析。
6. SQL優化問題
問題1，2，3，其實效率是一樣高的，因為現在的sqlserver,oracle,都有sql語句優化分析器，語句不同的寫法，到最後編譯之後，其實是一樣的。
4，如果對欄位like，而且是%key%這樣的方式，索引就不起作用了，所以加上索引也沒用。
7. 關於SQL資料庫優化
具體要注意的：
1.應盡量避免在 where 子句中對欄位進行 null 值判斷，否則將導致引擎放棄使用索引而進行全表掃描，如：
select id from t where num is null
可以在num上設置默認值0，確保表中num列沒有null值，然後這樣查詢：
select id from t where num=0
2.應盡量避免在 where 子句中使用!=或<>操作符，否則將引擎放棄使用索引而進行全表掃描。優化器將無法通過索引來確定將要命中的行數,因此需要搜索該表的所有行。
3.應盡量避免在 where 子句中使用 or 來連接條件，否則將導致引擎放棄使用索引而進行全表掃描，如：
select id from t where num=10 or num=20
可以這樣查詢：
select id from t where num=10
union all
select id from t where num=20
4.in 和 not in 也要慎用，因為IN會使系統無法使用索引,而只能直接搜索表中的數據。如：
select id from t where num in(1,2,3)
對於連續的數值，能用 between 就不要用 in 了：
select id from t where num between 1 and 3
5.盡量避免在索引過的字元數據中，使用非打頭字母搜索。這也使得引擎無法利用索引。
見如下例子：
SELECT * FROM T1 WHERE NAME LIKE 『%L%』
SELECT * FROM T1 WHERE SUBSTING(NAME,2,1)=』L』
SELECT * FROM T1 WHERE NAME LIKE 『L%』
即使NAME欄位建有索引，前兩個查詢依然無法利用索引完成加快操作，引擎不得不對全表所有數據逐條操作來完成任務。而第三個查詢能夠使用索引來加快操作。
6.必要時強制查詢優化器使用某個索引，如在 where 子句中使用參數，也會導致全表掃描。因為SQL只有在運行時才會解析局部變數，但優化程序不能將訪問計劃的選擇推遲到運行時；它必須在編譯時進行選擇。然而，如果在編譯時建立訪問計劃，變數的值還是未知的，因而無法作為索引選擇的輸入項。如下面語句將進行全表掃描：
select id from t where num=@num
可以改為強制查詢使用索引：
select id from t with(index(索引名)) where num=@num
7.應盡量避免在 where 子句中對欄位進行表達式操作，這將導致引擎放棄使用索引而進行全表掃描。如：
SELECT * FROM T1 WHERE F1/2=100
應改為:
SELECT * FROM T1 WHERE F1=100*2
SELECT * FROM RECORD WHERE SUBSTRING(CARD_NO,1,4)=』5378』
應改為:
SELECT * FROM RECORD WHERE CARD_NO LIKE 『5378%』
SELECT member_number, first_name, last_name FROM members
WHERE DATEDIFF(yy,datofbirth,GETDATE()) > 21
應改為:
SELECT member_number, first_name, last_name FROM members
WHERE dateofbirth < DATEADD(yy,-21,GETDATE())
即：任何對列的操作都將導致表掃描，它包括資料庫函數、計算表達式等等，查詢時要盡可能將操作移至等號右邊。
8.應盡量避免在where子句中對欄位進行函數操作，這將導致引擎放棄使用索引而進行全表掃描。如：
select id from t where substring(name,1,3)='abc'--name以abc開頭的id
select id from t where datediff(day,createdate,'2005-11-30')=0--『2005-11-30』生成的id
應改為:
select id from t where name like 'abc%'
select id from t where createdate>='2005-11-30' and createdate<'2005-12-1'
9.不要在 where 子句中的「=」左邊進行函數、算術運算或其他表達式運算，否則系統將可能無法正確使用索引。
10.在使用索引欄位作為條件時，如果該索引是復合索引，那麼必須使用到該索引中的第一個欄位作為條件時才能保證系統使用該索引，否則該索引將不會被使用，並且應盡可能的讓欄位順序與索引順序相一致。
11.很多時候用 exists是一個好的選擇：
select num from a where num in(select num from b)
用下面的語句替換：
select num from a where exists(select top 1 from b where num=a.num)
SELECT SUM(T1.C1)FROM T1 WHERE(
(SELECT COUNT(*)FROM T2 WHERE T2.C2=T1.C2>0)
SELECT SUM(T1.C1) FROM T1WHERE EXISTS(
SELECT * FROM T2 WHERE T2.C2=T1.C2)
兩者產生相同的結果，但是後者的效率顯然要高於前者。因為後者不會產生大量鎖定的表掃描或是索引掃描。
如果你想校驗表裡是否存在某條紀錄，不要用count(*)那樣效率很低，而且浪費伺服器資源。可以用EXISTS代替。如：
IF (SELECT COUNT(*) FROM table_name WHERE column_name = 'xxx')
可以寫成：
IF EXISTS (SELECT * FROM table_name WHERE column_name = 'xxx')
經常需要寫一個T_SQL語句比較一個父結果集和子結果集，從而找到是否存在在父結果集中有而在子結果集中沒有的記錄，如：
SELECT a.hdr_key FROM hdr_tbl a---- tbl a 表示tbl用別名a代替
WHERE NOT EXISTS (SELECT * FROM dtl_tbl b WHERE a.hdr_key = b.hdr_key)
SELECT a.hdr_key FROM hdr_tbl a
LEFT JOIN dtl_tbl b ON a.hdr_key = b.hdr_key WHERE b.hdr_key IS NULL
SELECT hdr_key FROM hdr_tbl
WHERE hdr_key NOT IN (SELECT hdr_key FROM dtl_tbl)
三種寫法都可以得到同樣正確的結果，但是效率依次降低。
12.盡量使用表變數來代替臨時表。如果表變數包含大量數據，請注意索引非常有限（只有主鍵索引）。
13.避免頻繁創建和刪除臨時表，以減少系統表資源的消耗。
14.臨時表並不是不可使用，適當地使用它們可以使某些常式更有效，例如，當需要重復引用大型表或常用表中的某個數據集時。但是，對於一次性事件，最好使用導出表。
15.在新建臨時表時，如果一次性插入數據量很大，那麼可以使用 select into 代替 create table，避免造成大量 log ，以提高速度；如果數據量不大，為了緩和系統表的資源，應先create table，然後insert。
16.如果使用到了臨時表，在存儲過程的最後務必將所有的臨時表顯式刪除，先 truncate table ，然後 drop table ，這樣可以避免系統表的較長時間鎖定。
17.在所有的存儲過程和觸發器的開始處設置 SET NOCOUNT ON ，在結束時設置 SET NOCOUNT OFF 。無需在執行存儲過程和觸發器的每個語句後向客戶端發送 DONE_IN_PROC 消息。
18.盡量避免大事務操作，提高系統並發能力。
19.盡量避免向客戶端返回大數據量，若數據量過大，應該考慮相應需求是否合理。
20. 避免使用不兼容的數據類型。例如float和int、char和varchar、binary和varbinary是不兼容的。數據類型的不兼容可能使優化器無法執行一些本來可以進行的優化操作。例如:
SELECT name FROM employee WHERE salary > 60000
在這條語句中,如salary欄位是money型的,則優化器很難對其進行優化,因為60000是個整型數。我們應當在編程時將整型轉化成為錢幣型,而不要等到運行時轉化。
21.充分利用連接條件，在某種情況下，兩個表之間可能不只一個的連接條件，這時在 WHERE 子句中將連接條件完整的寫上，有可能大大提高查詢速度。
例：
SELECT SUM(A.AMOUNT) FROM ACCOUNT A,CARD B WHERE A.CARD_NO = B.CARD_NO
SELECT SUM(A.AMOUNT) FROM ACCOUNT A,CARD B WHERE A.CARD_NO = B.CARD_NO AND A.ACCOUNT_NO=B.ACCOUNT_NO
第二句將比第一句執行快得多。
22、使用視圖加速查詢
把表的一個子集進行排序並創建視圖，有時能加速查詢。它有助於避免多重排序 操作，而且在其他方面還能簡化優化器的工作。例如：
SELECT cust.name，rcvbles.balance，……other columns
FROM cust，rcvbles
WHERE cust.customer_id = rcvlbes.customer_id
AND rcvblls.balance>0
AND cust.postcode>「98000」
ORDER BY cust.name
如果這個查詢要被執行多次而不止一次，可以把所有未付款的客戶找出來放在一個視圖中，並按客戶的名字進行排序：
CREATE VIEW DBO.V_CUST_RCVLBES
AS
SELECT cust.name，rcvbles.balance，……other columns
FROM cust，rcvbles
WHERE cust.customer_id = rcvlbes.customer_id
AND rcvblls.balance>0
ORDER BY cust.name
然後以下面的方式在視圖中查詢：
SELECT ＊ FROM V_CUST_RCVLBES
WHERE postcode>「98000」
視圖中的行要比主表中的行少，而且物理順序就是所要求的順序，減少了磁碟I/O，所以查詢工作量可以得到大幅減少。
23、能用DISTINCT的就不用GROUP BY
SELECT OrderID FROM Details WHERE UnitPrice > 10 GROUP BY OrderID
可改為：
SELECT DISTINCT OrderID FROM Details WHERE UnitPrice > 10
24.能用UNION ALL就不要用UNION
UNION ALL不執行SELECT DISTINCT函數，這樣就會減少很多不必要的資源
35.盡量不要用SELECT INTO語句。
SELECT INOT 語句會導致表鎖定，阻止其他用戶訪問該表。
上面我們提到的是一些基本的提高查詢速度的注意事項,但是在更多的情況下,往往需要反復試驗比較不同的語句以得到最佳方案。最好的方法當然是測試，看實現相同功能的SQL語句哪個執行時間最少，但是資料庫中如果數據量很少，是比較不出來的，這時可以用查看執行計劃，即：把實現相同功能的多條SQL語句考到查詢分析器，按CTRL+L看查所利用的索引，表掃描次數（這兩個對性能影響最大），總體上看詢成本百分比即可。
今天在itput上看了一篇文章，是討論一個語句的優化：
原貼地址： http://www.itpub.net/viewthread.php?tid=1015964&extra=&page=1
一，發現問題 優化的語句：
請問以下語句如何優化:
CREATE TABLE aa_001
( ip VARCHAR2(28),
name VARCHAR2(10),
password VARCHAR2(30) )
select * from aa_001 where ip in (1,2,3) order by name desc;
--目前表中記錄有一千多萬條左右，而且in中的值個數是不確定的。
以上就是優化的需要優化的語句和情況。
不少人在後面跟帖：有的說沒辦法優化，有的說將ＩＮ該為ＥＸＩＳＴＳ，有的說在ip上建立索引復合索引（ip，name)等等。
二，提出問題 那這樣的情況，能優化嗎，如何優化？今天就來討論這個問題。
三，分析問題 1，數據量1千萬多條。
2，in中的值個數是不確定
3.1 分析數據分布 這里作者沒有提到ip列的數據的分布情況，目前ip列的數據分布可能有以下幾種：
1，ip列（數據唯一，或者數據重復的概率很小）
2，ip列 (數據不均勻，可能有些數據重復多，有些重復少）
3，ip列 （數據分布比較均勻，數據大量重復，主要就是一些同樣的數據（可能只有上萬級別不同的ip數據等)
解決問題：
1，對於第一種數據分布情況，只要在ip列建立一個索引即可。這時不管表有多少行， in個數是不確定的情況下，都很快。
2，對應第二中數據分布情況，在ip列建立索引，效果不好。因為數據分布不均勻，可能有些快，有些慢
3，對應第三種數據分布情況，在ip列建立索引，速度肯定慢。
注意：這里的 order by name desc 是在取出數據後再排序的。而不是取數據前排序
對於2，3兩個情況，因為都是可能需要取出大量的數據，優化器就採用表掃描(table scan)，而不是索引查找(index seek) ,速度很慢，因為這時表掃描效率要優於索引查找，特別是高並發情況下，效率很低。
那對應2，3中情況，如何處理。是將in改成exists。其實在sql server 2005和oracle里的優化器在in後面數據少時，效率是一樣的。這時採用一般的索引效率很低。這時如果在ip列上建立聚集索引，效率會比較高。我們在SQL server 2005中做個測試。
表：[dbo].[[zping.com]]]中有約200萬條數據。包含列Userid, id, Ruleid等列。按照上面的情況查詢一下類似語句：
select * from [dbo].[[zping.com]]] where
userid in ('',''
,'') order by Ruleid desc
我們先看userid的數據分布情況，執行下面語句：
select userid,count(*) from [dbo].[[zping.com]]] group by userid order by 2
這時我們看看數據分布：總共有379條數據，數據兩從1到15萬都有，數據分布傾斜嚴重。下圖是其中一部分。
這時如果在ip上建立非聚集索引，效率很低，而且就是強行索引掃描，效率也很低，會發現IO次數比表掃描還高。這時只能在ip上建立聚集索引。這時看看結果。
這時發現，搜索採用了（clustered index seek）聚集搜索掃描。
在看看查詢返回的結果：
(156603 行受影響)
表 '[zping.com]'。掃描計數 8，邏輯讀取 5877 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次。
表 'Worktable'。掃描計數 0，邏輯讀取 0 次，物理讀取 0 次，預讀 0 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次。
返回15萬行，才不到6千次IO。效率較高，因為這15萬行要排序，查詢成本里排序佔了51%。當然可以建立（userid，Ruleid）復合聚集索引，提高性能，但這樣做DML維護成本較高。建議不採用。
從上面的測試例子可以看出， 優化的解決辦法：
數據分布為1：建立ip索引即可
數據分布為2，3：在ip列建立聚集索引。
8. 如何解決SQL查詢速度太慢
1. 執行計劃中明明有使用到索引，為什麼執行還是這么慢？
2. 執行計劃中顯示掃描行數為 644，為什麼 slow log 中顯示 100 多萬行？
a. 我們先看執行計劃，選擇的索引 「INDX_BIOM_ELOCK_TASK3(TASK_ID)」。結合 sql 來看，因為有 "ORDER BY TASK_ID DESC" 子句，排序通常很慢，如果使用了文件排序性能會更差，優化器選擇這個索引避免了排序。
那為什麼不選 possible_keys:INDX_BIOM_ELOCK_TASK 呢？原因也很簡單，TASK_DATE 欄位區分度太低了，走這個索引需要掃描的行數很大，而且還要進行額外的排序，優化器綜合判斷代價更大，所以就不選這個索引了。不過如果我們強制選擇這個索引（用 force index 語法），會看到 SQL 執行速度更快少於 10s，那是因為優化器基於代價的原則並不等價於執行速度的快慢；
b. 再看執行計劃中的 type:index，"index" 代表 「全索引掃描」，其實和全表掃描差不多，只是掃描的時候是按照索引次序進行而不是行，主要優點就是避免了排序，但是開銷仍然非常大。
Extra:Using where 也意味著掃描完索引後還需要回表進行篩選。一般來說，得保證 type 至少達到 range 級別，最好能達到 ref。
在第 2 點中提到的「慢日誌記錄Rows_examined: 1161559，看起來是全表掃描」，這里更正為「全索引掃描」，掃描行數確實等於表的行數；
c. 關於執行計劃中：「rows：644」，其實這個只是估算值，並不準確，我們分析慢 SQL 時判斷准確的掃描行數應該以 slow log 中的 Rows_examined 為准。
4. 優化建議：添加組合索引 IDX_REL_DEVID_TASK_ID(REL_DEVID,TASK_ID)
優化過程：
TASK_DATE 欄位存在索引，但是選擇度很低，優化器不會走這個索引，建議後續可以刪除這個索引：
select count(*),count(distinct TASK_DATE) from T_BIOMA_ELOCK_TASK;+------------+---------------------------+| count(*) | count(distinct TASK_DATE) |+------------+---------------------------+| 1161559 | 223 |+------------+---------------------------+
在這個 sql 中 REL_DEVID 欄位從命名上看選擇度較高，通過下面 sql 來檢驗確實如此：
select count(*),count(distinct REL_DEVID) from T_BIOMA_ELOCK_TASK;+----------+---------------------------+| count(*) | count(distinct REL_DEVID) |+----------+---------------------------+| 1161559 | 62235 |+----------+---------------------------+
由於有排序，所以得把 task_id 也加入到新建的索引中，REL_DEVID,task_id 組合選擇度 100%：
select count(*),count(distinct REL_DEVID,task_id) from T_BIOMA_ELOCK_TASK;+----------+-----------------------------------+| count(*) | count(distinct REL_DEVID,task_id) |+----------+-----------------------------------+| 1161559 | 1161559 |+----------+-----------------------------------+
在測試環境添加 REL_DEVID，TASK_ID 組合索引，測試 sql 性能：alter table T_BIOMA_ELOCK_TASK add index idx_REL_DEVID_TASK_ID(REL_DEVID,TASK_ID);
添加索引後執行計劃：
這里還要注意一點「隱式轉換」：REL_DEVID 欄位數據類型為 varchar，需要在 sql 中加引號：AND T.REL_DEVID = 000000025xxx >> AND T.REL_DEVID = '000000025xxx'
執行時間從 10s+ 降到 毫秒級別：
1 row in set (0.00 sec)
結論
一個典型的 order by 查詢的優化，添加更合適的索引可以避免性能問題：執行計劃使用索引並不意味著就能執行快。
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、整合簡單,無關聯的資料庫訪問：
如果你有幾個簡單的資料庫查詢語句,你可以把它們整合到一個查詢中(即使它們之間沒有關系)。
10. 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、一次更新多條記錄比分多次更新每次一條快,就是說批處理好 一定要採納哦