具體要注意的：
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列建立聚集索引。
2. SQL語句執行流程與順序原理解析
SQL語句執行流程與順序原理解析
Oracle語句執行流程
第一步：客戶端把語句發給伺服器端執行
當我們在客戶端執行SQL語句時，客戶端會把這條SQL語句發送給伺服器端，讓伺服器端的進程來處理這語句。也就是說，Oracle 客戶端是不會做任何的操作，他的主要任務就是把客戶端產生的一些SQL語句發送給伺服器端。伺服器進程從用戶進程把信息接收到後， 在PGA 中就要此進程分配所需內存，存儲相關的信息，如：在會話內存存儲相關的登錄信息等。
雖然在客戶端也有一個資料庫進程，但是，這個進程的作用跟伺服器上的進程作用是不相同的，伺服器上的資料庫進程才會對SQL 語句進行相關的處理。不過，有個問題需要說明，就是客戶端的進程跟伺服器的進程是一一對應的。也就是說，在客戶端連接上伺服器後，在客戶端與伺服器端都會形成一個進程，客戶端上的我們叫做客戶端進程，而伺服器上的我們叫做伺服器進程。
第二步：語句解析
當客戶端把SQL語句傳送到伺服器後，伺服器進程會對該語句進行解析。這個解析的工作是在伺服器端所進行的，解析動作又可分為很多小動作。
1）查詢高速緩存（library cache）
伺服器進程在接到客戶端傳送過來的SQL語句時，不會直接去資料庫查詢。伺服器進程把這個SQL語句的字元轉化為ASCII等效數字碼，接著這個ASCII碼被傳遞給一個HASH函數，並返回一個hash值，然後伺服器進程將到shared pool中的library cache（高速緩存）中去查找是否存在相同的hash值。如果存在，伺服器進程將使用這條語句已高速緩存在SHARED POOL的library cache中的已分析過的版本來執行，省去後續的解析工作，這便是軟解析。若調整緩存中不存在，則需要進行後面的步驟，這便是硬解析。硬解析通常是昂貴的操作，大約占整個SQL執行的70%左右的時間，硬解析會生成執行樹，執行計劃，等等。
所以，採用高速數據緩存的話，可以提高SQL 語句的查詢效率。其原因有兩方面：一方面是從內存中讀取數據要比從硬碟中的數據文件中讀取數據效率要高，另一方面也是因為避免語句解析而節省了時間。
不過這里要注意一點，這個數據緩存跟有些客戶端軟體的數據緩存是兩碼事。有些客戶端軟體為了提高查詢效率，會在應用軟體的客戶端設置數據緩存。由於這些數據緩存的存在，可以提高客戶端應用軟體的查詢效率。但是，若其他人在伺服器進行了相關的修改，由於應用軟體數據緩存的存在，導致修改的數據不能及時反映到客戶端上。從這也可以看出，應用軟體的數據緩存跟資料庫伺服器的高速數據緩存不是一碼事。
2）語句合法性檢查（data dict cache）
當在高速緩存中找不到對應的SQL語句時，則伺服器進程就會開始檢查這條語句的合法性。這里主要是對SQL語句的語法進行檢查，看看其是否合乎語法規則。如果伺服器進程認為這條SQL語句不符合語法規則的時候，就會把這個錯誤信息反饋給客戶端。在這個語法檢查的過程中，不會對SQL語句中所包含的表名、列名等等進行檢查，只是檢查語法。
3）語言含義檢查（data dict cache）
若SQL 語句符合語法上的定義的話，則伺服器進程接下去會對語句中涉及的表、索引、視圖等對象進行解析，並對照數據字典檢查這些對象的名稱以及相關結構，看看這些欄位、表、視圖等是否在資料庫中。如果表名與列名不準確的話，則資料庫會就會反饋錯誤信息給客戶端。
所以，有時候我們寫select語句的時候，若語法與表名或者列名同時寫錯的話，則系統是先提示說語法錯誤，等到語法完全正確後再提示說列名或表名錯誤。
4）獲得對象解析鎖（control structer）
當語法、語義都正確後，系統就會對我們需要查詢的對象加鎖。這主要是為了保障數據的一致性，防止我們在查詢的過程中，其他用戶對這個對象的結構發生改變。
5）數據訪問許可權的核對（data dict cache）
當語法、語義通過檢查之後，客戶端還不一定能夠取得數據，伺服器進程還會檢查連接用戶是否有這個數據訪問的許可權。若用戶不具有數據訪問許可權的話，則客戶端就不能夠取得這些數據。要注意的是資料庫伺服器進程先檢查語法與語義，然後才會檢查訪問許可權。
6）確定最佳執行計劃
當語法與語義都沒有問題許可權也匹配，伺服器進程還是不會直接對資料庫文件進行查詢。伺服器進程會根據一定的規則，對這條語句進行優化。在執行計劃開發之前會有一步查詢轉換，如：視圖合並、子查詢解嵌套、謂語前推及物化視圖重寫查詢等。為了確定採用哪個執行計劃，Oracle還需要收集統計信息確定表的訪問聯結方法等，最終確定可能的最低成本的執行計劃。
不過要注意，這個優化是有限的。一般在應用軟體開發的過程中，需要對資料庫的sql語句進行優化，這個優化的作用要大大地大於伺服器進程的自我優化。
當伺服器進程的優化器確定這條查詢語句的最佳執行計劃後， 就會將這條SQL語句與執行計劃保存到數據高速緩存（library cache）。如此，等以後還有這個查詢時，就會省略以上的語法、語義與許可權檢查的步驟，而直接執行SQL語句，提高SQL語句處理效率。
第三步：綁定變數賦值
如果SQL語句中使用了綁定變數，掃描綁定變數的聲明，給綁定變數賦值，將變數值帶入執行計劃。若在解析的第一個步驟，SQL在高速緩沖中存在，則直接跳到該步驟。
第四步：語句執行
語句解析只是對SQL語句的語法進行解析，以確保伺服器能夠知道這條語句到底表達的是什麼意思。等到語句解析完成之後，資料庫伺服器進程才會真正的執行這條SQL語句。
對於SELECT語句：
1）首先伺服器進程要判斷所需數據是否在db buffer存在，如果存在且可用，則直接獲取該數據而不是從資料庫文件中去查詢數據，同時根據LRU 演算法增加其訪問計數；
2）若數據不在緩沖區中，則伺服器進程將從資料庫文件中查詢相關數據，並把這些數據放入到數據緩沖區中（buffer cache）。
其中，若數據存在於db buffer，其可用性檢查方式為：查看db buffer塊的頭部是否有事務，如果有事務，則從回滾段中讀取數據；如果沒有事務，則比較select的scn和db buffer塊頭部的scn，如果前者小於後者，仍然要從回滾段中讀取數據；如果前者大於後者，說明這是一非臟緩存，可以直接讀取這個db buffer塊的中內容。
對於DML語句（insert、delete、update）：
1）檢查所需的資料庫是否已經被讀取到緩沖區緩存中。如果已經存在緩沖區緩存，則直接執行步驟3；
2）若所需的資料庫並不在緩沖區緩存中，則伺服器將數據塊從數據文件讀取到緩沖區緩存中；
3）對想要修改的表取得的數據行鎖定（Row Exclusive Lock），之後對所需要修改的數據行取得獨占鎖；
4）將數據的Redo記錄復制到redo log buffer；
5）產生數據修改的undo數據；
6）修改db buffer；
7）dbwr將修改寫入數據文件；
其中，第2步，伺服器將數據從數據文件讀取到db buffer經經歷以下步驟：
1）首先伺服器進程將在表頭部請求TM鎖（保證此事務執行過程其他用戶不能修改表的結構），如果成功加TM鎖，再請求一些行級鎖（TX鎖），如果TM、TX鎖都成功加鎖，那麼才開始從數據文件讀數據。
2）在讀數據之前，要先為讀取的文件准備好buffer空間。伺服器進程需要掃描LRU list尋找free db buffer，掃描的過程中，伺服器進程會把發現的所有已經被修改過的db buffer注冊到dirty list中。如果free db buffer及非臟數據塊緩沖區不足時，會觸發dbwr將dirty buffer中指向的緩沖塊寫入數據文件，並且清洗掉這些緩沖區來騰出空間緩沖新讀入的數據。
3）找到了足夠的空閑buffer，伺服器進程將從數據文件中讀入這些行所在的每一個數據塊（db block）（DB BLOCK是ORACLE的最小操作單元，即使你想要的數據只是DB BLOCK中很多行中的一行或幾行，ORACLE也會把這個DB BLOCK中的所有行都讀入Oracle DB BUFFER中）放入db buffer的空閑的區域或者覆蓋已被擠出LRU list的非臟數據塊緩沖區，並且排列在LRU列表的頭部，也就是在數據塊放入db buffer之前也是要先申請db buffer中的鎖存器，成功加鎖後，才能讀數據到db buffer。
若數據塊已經存在於db buffer cache（有時也稱db buffer或db cache），即使在db buffer中找到一個沒有事務，而且SCN比自己小的非臟緩存數據塊，伺服器進程仍然要到表的頭部對這條記錄申請加鎖，加鎖成功才能進行後續動作，如果不成功，則要等待前面的進程解鎖後才能進行動作（這個時候阻塞是tx鎖阻塞）。
在記redo日誌時，其具體步驟如下：
1）數據被讀入到db buffer後，伺服器進程將該語句所影響的並被讀入db buffer中的這些行數據的rowid及要更新的原值和新值及scn等信息從PGA逐條的寫入redo log buffer中。在寫入redo log buffer之前也要事先請求redo log buffer的鎖存器，成功加鎖後才開始寫入。
2）當寫入達到redo log buffer大小的三分之一或寫入量達到1M或超過三秒後或發生檢查點時或者dbwr之前發生，都會觸發lgwr進程把redo log buffer的數據寫入磁碟上的redo file文件中（這個時候會產生log file sync等待事件）。
3）已經被寫入redo file的redo log buffer所持有的鎖存器會被釋放，並可被後來的寫入信息覆蓋，redo log buffer是循環使用的。Redo file也是循環使用的，當一個redo file寫滿後，lgwr進程會自動切換到下一redo file（這個時候可能出現log file switch（check point complete）等待事件）。如果是歸檔模式，歸檔進程還要將前一個寫滿的redo file文件的內容寫到歸檔日誌文件中（這個時候可能出現log file switch（archiving needed）。
在為事務建立undo信息時，其具體步驟如下：
1）在完成本事務所有相關的redo log buffer之後，伺服器進程開始改寫這個db buffer的塊頭部事務列表並寫入scn（一開始scn是寫在redo log buffer中的，並未寫在db buffer）。
2）然後包含這個塊的頭部事務列表及scn信息的數據副本放入回滾段中，將這時回滾段中的信息稱為數據塊的「前映像」，這個「前映像」用於以後的回滾、恢復和一致性讀。（回滾段可以存儲在專門的回滾表空間中，這個表空間由一個或多個物理文件組成，並專用於回滾表空間，回滾段也可在其它表空間中的數據文件中開辟）。
在修改信息寫入數據文件時，其具體步驟如下：
1）改寫db buffer塊的數據內容，並在塊的頭部寫入回滾段的地址。
2）將db buffer指針放入dirty list。如果一個行數據多次update而未commit，則在回滾段中將會有多個「前映像」，除了第一個「前映像」含有scn信息外，其他每個"前映像"的頭部都有scn信息和"前前映像"回滾段地址。一個update只對應一個scn，然後伺服器進程將在dirty list中建立一條指向此db buffer塊的指針（方便dbwr進程可以找到dirty list的db buffer數據塊並寫入數據文件中）。接著伺服器進程會從數據文件中繼續讀入第二個數據塊，重復前一數據塊的動作，數據塊的讀入、記日誌、建立回滾段、修改數據塊、放入dirty list。
3）當dirty queue的長度達到閥值（一般是25%），伺服器進程將通知dbwr把臟數據寫出，就是釋放db buffer上的鎖存器，騰出更多的free db buffer。前面一直都是在說明oracle一次讀一個數據塊，其實oracle可以一次讀入多個數據塊（db_file_multiblock_read_count來設置一次讀入塊的個數）
當執行commit時，具體步驟如下：
1）commit觸發lgwr進程，但不強制dbwr立即釋放所有相應db buffer塊的鎖。也就是說有可能雖然已經commit了，但在隨後的一段時間內dbwr還在寫這條sql語句所涉及的數據塊。表頭部的行鎖並不在commit之後立即釋放，而是要等dbwr進程完成之後才釋放，這就可能會出現一個用戶請求另一用戶已經commit的資源不成功的現象。
2）從Commit和dbwr進程結束之間的時間很短，如果恰巧在commit之後，dbwr未結束之前斷電，因為commit之後的數據已經屬於數據文件的內容，但這部分文件沒有完全寫入到數據文件中。所以需要前滾。由於commit已經觸發lgwr，這些所有未來得及寫入數據文件的更改會在實例重啟後，由smon進程根據重做日誌文件來前滾，完成之前commit未完成的工作（即把更改寫入數據文件）。
3）如果未commit就斷電了，因為數據已經在db buffer更改了，沒有commit，說明這部分數據不屬於數據文件。由於dbwr之前觸發lgwr也就是只要數據更改，（肯定要先有log）所有dbwr在數據文件上的修改都會被先一步記入重做日誌文件，實例重啟後，SMON進程再根據重做日誌文件來回滾。
其實smon的前滾回滾是根據檢查點來完成的，當一個全部檢查點發生的時候，首先讓LGWR進程將redologbuffer中的所有緩沖（包含未提交的重做信息）寫入重做日誌文件，然後讓dbwr進程將dbbuffer已提交的緩沖寫入數據文件（不強制寫未提交的）。然後更新控制文件和數據文件頭部的SCN，表明當前資料庫是一致的，在相鄰的兩個檢查點之間有很多事務，有提交和未提交的。
當執行rollback時，具體步驟如下：
伺服器進程會根據數據文件塊和db buffer中塊的頭部的事務列表和SCN以及回滾段地址找到回滾段中相應的修改前的副本，並且用這些原值來還原當前數據文件中已修改但未提交的改變。如果有多個」前映像「，伺服器進程會在一個「前映像」的頭部找到「前前映像」的回滾段地址，一直找到同一事務下的最早的一個「前映像」為止。一旦發出了commit，用戶就不能rollback，這使得commit後dbwr進程還沒有全部完成的後續動作得到了保障。
第五步：提取數據
當語句執行完成之後，查詢到的數據還是在伺服器進程中，還沒有被傳送到客戶端的用戶進程。所以，在伺服器端的進程中，有一個專門負責數據提取的一段代碼。他的作用就是把查詢到的數據結果返回給用戶端進程，從而完成整個查詢動作。
從這整個查詢處理過程中，我們在資料庫開發或者應用軟體開發過程中，需要注意以下幾點：
一是要了解資料庫緩存跟應用軟體緩存是兩碼事情。資料庫緩存只有在資料庫伺服器端才存在，在客戶端是不存在的。只有如此，才能夠保證資料庫緩存中的內容跟資料庫文件的內容一致。才能夠根據相關的規則，防止數據臟讀、錯讀的發生。而應用軟體所涉及的數據緩存，由於跟資料庫緩存不是一碼事情，所以，應用軟體的數據緩存雖然可以提高數據的查詢效率，但是，卻打破了數據一致性的要求，有時候會發生臟讀、錯讀等情況的發生。所以，有時候，在應用軟體上有專門一個功能，用來在必要的時候清除數據緩存。不過，這個數據緩存的清除，也只是清除本機上的數據緩存，或者說，只是清除這個應用程序的數據緩存，而不會清除資料庫的數據緩存。
二是絕大部分SQL語句都是按照這個處理過程處理的。我們DBA或者基於Oracle資料庫的開發人員了解這些語句的處理過程，對於我們進行涉及到SQL語句的開發與調試，是非常有幫助的。有時候，掌握這些處理原則，可以減少我們排錯的時間。特別要注意，資料庫是把數據查詢許可權的審查放在語法語義的後面進行檢查的。所以，有時會若光用資料庫的許可權控制原則，可能還不能滿足應用軟體許可權控制的需要。此時，就需要應用軟體的前台設置，實現許可權管理的要求。而且，有時應用資料庫的許可權管理，也有點顯得繁瑣，會增加伺服器處理的工作量。因此，對於記錄、欄位等的查詢許可權控制，大部分程序涉及人員喜歡在應用程序中實現，而不是在資料庫上實現。
Oracle SQL語句執行順序
(8)SELECT (9) DISTINCT (11) <select_list>
(1) FROM <left_table>
(3) <join_type> JOIN <right_table>
(2) ON <join_condition>
(4) WHERE <where_condition>
(5) GROUP BY <group_by_list>
(6) WITH {CUBE | ROLLUP}
(7) HAVING <having_condition>
(10) ORDER BY <order_by_list>
1）FROM：對FROM子句中的表執行笛卡爾積(交叉聯接)，生成虛擬表VT1。
2）ON：對VT1應用ON篩選器，只有那些使為真才被插入到TV2。
3）OUTER (JOIN):如果指定了OUTER JOIN(相對於CROSS JOIN或INNER JOIN)，保留表中未找到匹配的行將作為外部行添加到VT2，生成TV3。如果FROM子句包含兩個以上的表，則對上一個聯接生成的結果表和下一個表重復執行步驟1到步驟3，直到處理完所有的表位置。
4）WHERE：對TV3應用WHERE篩選器，只有使為true的行才插入TV4。
5）GROUP BY：按GROUP BY子句中的列列表對TV4中的行進行分組，生成TV5。
6）CUTE|ROLLUP：把超組插入VT5，生成VT6。
7）HAVING：對VT6應用HAVING篩選器，只有使為true的組插入到VT7。
8）SELECT：處理SELECT列表，產生VT8。
9）DISTINCT：將重復的行從VT8中刪除，產品VT9。
10）ORDER BY：將VT9中的行按ORDER BY子句中的列列表順序，生成一個游標(VC10)，生成表TV11，並返回給調用者。
以上每個步驟都會產生一個虛擬表，該虛擬表被用作下一個步驟的輸入。這些虛擬表對調用者(客戶端應用程序或者外部查詢)不可用。只有最後一步生成的表才會會給調用者。如果沒有在查詢中指定某一個子句，將跳過相應的步驟。
3. DB2問題，程序運行時不定時出現以下sql報錯問題！
-911錯誤有兩種可能：
一、死鎖
二、超時
從你使用事務上來看，請檢查你的事務是否提交；如果有提交，那麼如果採用多重並發事務操作的時候，且在程序要返回結果集的時候，建議你將事務做簡單的操作，而不是大量數據操作，等待反饋結果。這樣的話，用戶可能會失去耐心，從而加快更多的進程進行並發操作，增加並發事務量。
根據你的情況，給你如下建議：
一、根據你的需求，將反饋結果，進行小時更新或日更新；
二、根據你的實際況情，優化事務SQL語句；盡量採用中間表（沒辦法，DB2的數據特性）
三、延長超時設置
四、跟蹤你的事務，保證事物完整性提交，盡可能減少死鎖。
死鎖分析方法：
用實例用戶連接到db2實例，切換到死鎖監視器路徑下，運行db2evmon -path xxx >lock_rpt.txt來生成報告
4. mysql的sql語句優化5種方式
只有5種嗎？我知道十種以上的說。
索引（沒我得全表查詢了）
改變數據儲引擎（MyISAM沒事務再也不用擔心鎖表了）
增加冗餘數來減少連表查詢數（消耗硬碟空間減少CPU使用）
調整查詢順序減少查詢量優先（數量少了連表的笛卡兒積也少了）
全文索引（文字長度有限制，而且IO使用量會大增，但是妥妥的快）
查詢盡量不要用函數（函數可是不走索引的哦親）
查詢變數類型要提前對好減少系統負擔（我提前改變了系統你就不用檢測了）
升級伺服器硬體（沒什麼是氪金解決不了的）
配置好臨時表空間，合理理由臨時表減少主表查詢搶資源（唯我獨查）
合理理由函數減少系統的判斷（明明都能確認內容不同你用UNION 系統還是傻傻的查一遍是否重復UNION ALL則跳過這個步驟同理 inner join 和 left join 也一樣）
強制走索引（復合索引的情況有時候手動走比系統判斷要好哦）
臟讀、幻讀等（你堵車我繞路）
數據歸檔，遷移（沒用的數據要進倉哦，別占著主表的資源）
表的碎片整理（遷移後碎片整理更健康哦親）
索引重構（數據都走了索引也應該重構一下才能保證速度哦）
善用存儲過程（串N個表（N大於10）的查詢千萬別一個SQL到底，分布式查詢在吧結果集合並吧騷年）
預處理數據（mysql也有job哦，對於經常要子查詢的數據可以先弄個明細表根據主表在後台進行補完，查詢的時候就更方便了）
懶得說了。。。。。。。。。。。。。。。。。。
5. SQL語句執行過程詳解
SQL語句執行過程詳解
一條sql，plsql的執行到底是怎樣執行的呢？
一、SQL語句執行原理：
第一步:客戶端把語句發給伺服器端執行當我們在客戶端執行 select 語句時,客戶端會把這條 SQL 語句發送給伺服器端,讓伺服器端的
進程來處理這語句。也就是說,Oracle 客戶端是不會做任何的操作,他的主要任務就是把客戶端產生
的一些 SQL 語句發送給伺服器端。雖然在客戶端也有一個資料庫進程,但是,這個進程的作用跟伺服器
上的進程作用事不相同的。伺服器上的資料庫進程才會對SQL 語句進行相關的處理。不過,有個問題需
要說明,就是客戶端的進程跟伺服器的進程是一一對應的。也就是說,在客戶端連接上伺服器後,在客戶
端與伺服器端都會形成一個進程,客戶端上的我們叫做客戶端進程;而伺服器上的我們叫做伺服器進程。
第二步:語句解析
當客戶端把 SQL 語句傳送到伺服器後,伺服器進程會對該語句進行解析。同理,這個解析的工作,
也是在伺服器端所進行的。雖然這只是一個解析的動作,但是,其會做很多「小動作」。
1. 查詢高速緩存(library cache)。伺服器進程在接到客戶端傳送過來的 SQL 語句時,不
會直接去資料庫查詢。而是會先在資料庫的高速緩存中去查找,是否存在相同語句的執行計劃。如果在
數據高速緩存中,則伺服器進程就會直接執行這個 SQL 語句,省去後續的工作。所以,採用高速數據緩
存的話,可以提高 SQL 語句的查詢效率。一方面是從內存中讀取數據要比從硬碟中的數據文件中讀取
數據效率要高,另一方面,也是因為這個語句解析的原因。
不過這里要注意一點,這個數據緩存跟有些客戶端軟體的數據緩存是兩碼事。有些客戶端軟體為了
提高查詢效率,會在應用軟體的客戶端設置數據緩存。由於這些數據緩存的存在,可以提高客戶端應用軟
件的查詢效率。但是,若其他人在伺服器進行了相關的修改,由於應用軟體數據緩存的存在,導致修改的
數據不能及時反映到客戶端上。從這也可以看出,應用軟體的數據緩存跟資料庫伺服器的高速數據緩存
不是一碼事。
2. 語句合法性檢查(data dict cache)。當在高速緩存中找不到對應的 SQL 語句時,則服
務器進程就會開始檢查這條語句的合法性。這里主要是對 SQL 語句的語法進行檢查,看看其是否合乎
語法規則。如果伺服器進程認為這條 SQL 語句不符合語法規則的時候,就會把這個錯誤信息,反饋給客
戶端。在這個語法檢查的過程中,不會對 SQL 語句中所包含的表名、列名等等進行 SQL 他只是語法
上的檢查。
3. 語言含義檢查(data dict cache)。若 SQL 語句符合語法上的定義的話,則伺服器進程
接下去會對語句中的欄位、表等內容進行檢查。看看這些欄位、表是否在資料庫中。如果表名與列名不
准確的話,則資料庫會就會反饋錯誤信息給客戶端。所以,有時候我們寫 select 語句的時候,若語法
與表名或者列名同時寫錯的話,則系統是先提示說語法錯誤,等到語法完全正確後,再提示說列名或表名
錯誤。
4. 獲得對象解析鎖(control structer)。當語法、語義都正確後,系統就會對我們需要查詢
的對象加鎖。這主要是為了保障數據的一致性,防止我們在查詢的過程中,其他用戶對這個對象的結構發
生改變。
5. 數據訪問許可權的核對(data dict cache)。當語法、語義通過檢查之後,客戶端還不一定
能夠取得數據。伺服器進程還會檢查,你所連接的用戶是否有這個數據訪問的許可權。若你連接上伺服器
的用戶不具有數據訪問許可權的話,則客戶端就不能夠取得這些數據。有時候我們查詢數據的時候,辛辛苦
苦地把 SQL 語句寫好、編譯通過,但是,最後系統返回個 「沒有許可權訪問數據」的錯誤信息,讓我們氣
半死。這在前端應用軟體開發調試的過程中,可能會碰到。所以,要注意這個問題,資料庫伺服器進程先
檢查語法與語義,然後才會檢查訪問許可權。
6. 確定最佳執行計劃 ?。當語句與語法都沒有問題,許可權也匹配的話,伺服器進程還是不會直接對
資料庫文件進行查詢。伺服器進程會根據一定的規則,對這條語句進行優化。不過要注意,這個優化是有
限的。一般在應用軟體開發的過程中,需要對資料庫的 sql 語言進行優化,這個優化的作用要大大地大
於伺服器進程的自我優化。所以,一般在應用軟體開發的時候,資料庫的優化是少不了的。當伺服器進程
的優化器確定這條查詢語句的最佳執行計劃後,就會將這條 SQL 語句與執行計劃保存到數據高速緩存
(library cache)。如此的話,等以後還有這個查詢時,就會省略以上的語法、語義與許可權檢查的步驟,
而直接執行 SQL 語句,提高 SQL 語句處理效率。
第三步:語句執行
語句解析只是對 SQL 語句的語法進行解析,以確保伺服器能夠知道這條語句到底表達的是什麼意
思。等到語句解析完成之後,資料庫伺服器進程才會真正的執行這條 SQL 語句。這個語句執行也分兩
種情況。
一是若被選擇行所在的數據塊已經被讀取到數據緩沖區的話,則伺服器進程會直接把這個數據傳遞
給客戶端,而不是從資料庫文件中去查詢數據。
若數據不在緩沖區中,則伺服器進程將從資料庫文件中查詢相關數據,並把這些數據放入到數據緩沖
區中(buffer cache)。
第四步:提取數據
當語句執行完成之後,查詢到的數據還是在伺服器進程中,還沒有被傳送到客戶端的用戶進程。所以,
在伺服器端的進程中,有一個專門負責數據提取的一段代碼。他的作用就是把查詢到的數據結果返回給
用戶端進程,從而完成整個查詢動作。從這整個查詢處理過程中,我們在資料庫開發或者應用軟體開發過
程中,需要注意以下幾點:
一是要了解資料庫緩存跟應用軟體緩存是兩碼事情。資料庫緩存只有在資料庫伺服器端才存在,在
客戶端是不存在的。只有如此,才能夠保證資料庫緩存中的內容跟資料庫文件的內容一致。才能夠根據
相關的規則,防止數據臟讀、錯讀的發生。而應用軟體所涉及的數據緩存,由於跟資料庫緩存不是一碼事
情,所以,應用軟體的數據緩存雖然可以提高數據的查詢效率,但是,卻打破了數據一致性的要求,有時候
會發生臟讀、錯讀等情況的發生。所以,有時候,在應用軟體上有專門一個功能,用來在必要的時候清除
數據緩存。不過,這個數據緩存的清除,也只是清除本機上的數據緩存,或者說,只是清除這個應用程序
的數據緩存,而不會清除資料庫的數據緩存。
二是絕大部分 SQL 語句都是按照這個處理過程處理的。我們 DBA 或者基於 Oracle 資料庫的
開發人員了解這些語句的處理過程,對於我們進行涉及到 SQL 語句的開發與調試,是非常有幫助的。有
時候,掌握這些處理原則,可以減少我們排錯的時間。特別要注意,資料庫是把數據查詢許可權的審查放在
語法語義的後面進行檢查的。所以,有時會若光用資料庫的許可權控制原則,可能還不能滿足應用軟體許可權
控制的需要。此時,就需要應用軟體的前台設置,實現許可權管理的要求。而且,有時應用資料庫的許可權管
理,也有點顯得繁瑣,會增加伺服器處理的工作量。因此,對於記錄、欄位等的查詢許可權控制,大部分程
序涉及人員喜歡在應用程序中實現,而不是在資料庫上實現。
DBCC DROPCLEANBUFFERS
從緩沖池中刪除所有清除緩沖區。
DBCC FREEPROCCACHE
從過程緩存中刪除所有元素。
DBCC FREESYSTEMCACHE
從所有緩存中釋放所有未使用的緩存條目
SQL語句中的函數、關鍵字、排序等執行順序:
1. FROM 子句返回初始結果集。
2. WHERE 子句排除不滿足搜索條件的行。
3. GROUP BY 子句將選定的行收集到 GROUP BY 子句中各個唯一值的組中。
4. 選擇列表中指定的聚合函數可以計算各組的匯總值。
5. 此外,HAVING 子句排除不滿足搜索條件的行。
6. 計算所有的表達式;
7. 使用 order by 對結果集進行排序。
8. 查找你要搜索的欄位。
二、SQL語句執行完整過程：
1.用戶進程提交一個 sql 語句:
update temp set a=a*2，給伺服器進程。
2.伺服器進程從用戶進程把信息接收到後,在 PGA 中就要此進程分配所需內存,存儲相關的信息,如在會
話內存存儲相關的登錄信息等。
3.伺服器進程把這個 sql 語句的字元轉化為 ASCII 等效數字碼,接著這個 ASCII 碼被傳遞給一個
HASH 函數,並返回一個 hash 值,然後伺服器進程將到shared pool 中的 library cache 中去查找是否存在相
同的 hash 值,如果存在,伺服器進程將使用這條語句已高速緩存在 SHARED POOL 的library cache 中的已
分析過的版本來執行。
4.如果不存在,伺服器進程將在 CGA 中,配合 UGA 內容對 sql,進行語法分析,首先檢查語法的正確性,接
著對語句中涉及的表,索引,視圖等對象進行解析,並對照數據字典檢查這些對象的名稱以及相關結構，並根據
ORACLE 選用的優化模式以及數據字典中是否存在相應對象的統計數據和是否使用了存儲大綱來生成一個
執行計劃或從存儲大綱中選用一個執行計劃,然後再用數據字典核對此用戶對相應對象的執行許可權,最後生成
一個編譯代碼。
5.ORACLE 將這條 sql 語句的本身實際文本、HASH 值、編譯代碼、與此語名相關聯的任何統計數據
和該語句的執行計劃緩存在 SHARED POOL 的 library cache中。伺服器進程通過 SHARED POOL 鎖存
器(shared pool latch)來申請可以向哪些共享 PL/SQL 區中緩存這此內容,也就是說被SHARED POOL 鎖存
器鎖定的 PL/SQL 區中的塊不可被覆蓋,因為這些塊可能被其它進程所使用。
6.在 SQL 分析階段將用到 LIBRARY
CACHE,從數據字典中核對表、視圖等結構的時候,需要將數據
字典從磁碟讀入 LIBRARY
CACHE,因此,在讀入之前也要使用LIBRARY
CACHE 鎖存器(library cache
pin,library cache lock)來申請用於緩存數據字典。 到現在為止,這個 sql 語句已經被編譯成可執行的代碼了,
但還不知道要操作哪些數據,所以伺服器進程還要為這個 sql 准備預處理數據。
7.首先伺服器進程要判斷所需數據是否在 db buffer 存在,如果存在且可用,則直接獲取該數據,同時根據
LRU 演算法增加其訪問計數;如果 buffer 不存在所需數據,則要從數據文件上讀取首先伺服器進程將在表頭部
請求 TM 鎖(保證此事務執行過程其他用戶不能修改表的結構),如果成功加 TM 鎖,再請求一些行級鎖(TX
鎖),如果 TM、TX 鎖都成功加鎖,那麼才開始從數據文件讀數據,在讀數據之前,要先為讀取的文件准備好
buffer 空間。伺服器進程需要掃面 LRU list 尋找 free db buffer,掃描的過程中,伺服器進程會把發現的所有
已經被修改過的 db buffer 注冊到 dirty list 中, 這些 dirty buffer 會通過 dbwr 的觸發條件,隨後會被寫出到
數據文件,找到了足夠的空閑 buffer,就可以把請求的數據行所在的數據塊放入到 db buffer 的空閑區域或者
覆蓋已經被擠出 LRU list 的非臟數據塊緩沖區,並排列在 LRU list 的頭部,也就是在數據塊放入 DB
BUFFER 之前也是要先申請 db buffer 中的鎖存器,成功加鎖後,才能讀數據到 db buffer。
8.記日誌 現在數據已經被讀入到 db buffer 了,現在伺服器進程將該語句所影響的並被讀
入 db buffer 中的這些行數據的 rowid 及要更新的原值和新值及 scn 等信息從 PGA 逐條的寫入 redo log
buffer 中。在寫入 redo log buffer 之前也要事先請求 redo log buffer 的鎖存器,成功加鎖後才開始寫入,當
寫入達到 redo log buffer 大小的三分之一或寫入量達到 1M 或超過三秒後或發生檢查點時或者 dbwr 之前
發生,都會觸發 lgwr 進程把 redo log buffer 的數據寫入磁碟上的 redo file 文件中(這個時候會產生log file
sync 等待事件)
已經被寫入 redofile 的 redo log buffer 所持有的鎖存器會被釋放,並可被後來的寫入信息覆蓋,
redo log buffer是循環使用的。Redo file 也是循環使用的,當一個 redo file 寫滿後,lgwr 進程會自動切換到
下一 redo file(這個時候可能出現 log fileswitch(checkpoint complete)等待事件)。如果是歸檔模式,歸檔進
程還要將前一個寫滿的 redo file 文件的內容寫到歸檔日誌文件中(這個時候可能出現 log file
switch(archiving needed)。
9.為事務建立回滾段 在完成本事務所有相關的 redo log buffer 之後,伺服器進程開始改寫這個 db buffer
的塊頭部事務列表並寫入 scn,然後 包含這個塊的頭部事務列表及 scn 信息的數據副本放入回滾段中,將
這時回滾段中的信息稱為數據塊的「前映像「,這個」前映像「用於以後的回滾、恢復和一致性讀。(回滾段可以
存儲在專門的回滾表空間中,這個表空間由一個或多個物理文件組成,並專用於回滾表空間,回滾段也可在其它
表空間中的數據文件中開辟。
10.本事務修改數據塊 准備工作都已經做好了,現在可以改寫 db buffer 塊的數據內容了,並在塊的頭部寫
入回滾段的地址。
11.放入 dirty list 如果一個行數據多次 update 而未 commit,則在回滾段中將會有多個「前映像「,除了第
一個」前映像「含有 scn 信息外,其他每個「前映像「的頭部都有 scn 信息和「前前映像」回滾段地址。一個
update 只對應一個 scn,然後伺服器進程將在 dirty list 中建立一
條指向此 db buffer 塊的指針(方便 dbwr 進程可以找到 dirty list 的 db buffer 數據塊並寫入數據文件中)。
接著伺服器進程會從數據文件中繼續讀入第二個數據塊,重復前一數據塊的動作,數據塊的讀入、記日誌、建
立回滾段、修改數據塊、放入 dirty list。當 dirty queue 的長度達到閥值(一般是 25%),伺服器進程將通知
dbwr 把臟數據寫出,就是釋放 db buffer 上的鎖存器,騰出更多的 free db buffer。前面一直都是在說明
oracle 一次讀一個數據塊,其實 oracle 可以一次讀入多個數據塊(db_file_multiblock_read_count 來設置一
次讀入塊的個數)
說明:
在預處理的數據已經緩存在 db buffer 或剛剛被從數據文件讀入到 db buffer 中,就要根據 sql 語句
的類型來決定接下來如何操作。
1>如果是 select 語句,則要查看 db buffer 塊的頭部是否有事務,如果有事務,則從回滾段中讀取數據;如
果沒有事務,則比較 select 的 scn 和 db buffer 塊頭部的 scn,如果前者小於後者,仍然要從回滾段中讀取數據;
如果前者大於後者,說明這是一非臟緩存,可以直接讀取這個 db buffer 塊的中內容。
2>如果是 DML 操作,則即使在 db buffer 中找到一個沒有事務,而且 SCN 比自己小的非臟
緩存數據塊,伺服器進程仍然要到表的頭部對這條記錄申請加鎖,加鎖成功才能進行後續動作,如果不成功,則要
等待前面的進程解鎖後才能進行動作(這個時候阻塞是 tx 鎖阻塞)。
用戶 commit 或 rollback 到現在為止,數據已經在 db buffer 或數據文件中修改完
成,但是否要永久寫到數文件中,要由用戶來決定 commit(保存更改到數據文件) rollback 撤銷數據的更改)。
1.用戶執行 commit 命令
只有當 sql 語句所影響的所有行所在的最後一個塊被讀入 db buffer 並且重做信息被寫入 redo log
buffer(僅指日誌緩沖區,而不包括日誌文件)之後,用戶才可以發去 commit 命令,commit 觸發 lgwr 進程,但不
強制立即 dbwr來釋放所有相應 db buffer 塊的鎖(也就是no-force-at-commit,即提交不強制寫),也就是說有
可能雖然已經 commit 了,但在隨後的一段時間內 dbwr 還在寫這條 sql 語句所涉及的數據塊。表頭部的行鎖
並不在 commit 之後立即釋放,而是要等 dbwr 進程完成之後才釋放,這就可能會出現一個用戶請求另一用戶
已經 commit 的資源不成功的現象。
A .從 Commit 和 dbwr 進程結束之間的時間很短,如果恰巧在 commit 之後,dbwr 未結束之前斷電,因為
commit 之後的數據已經屬於數據文件的內容,但這部分文件沒有完全寫入到數據文件中。所以需要前滾。由
於 commit 已經觸發 lgwr,這些所有未來得及寫入數據文件的更改會在實例重啟後,由 smon 進程根據重做日
志文件來前滾,完成之前 commit 未完成的工作(即把更改寫入數據文件)。
B.如果未 commit 就斷電了,因為數據已經在 db buffer 更改了,沒有 commit,說明這部分數據不屬於數
據文件,由於 dbwr 之前觸發 lgwr 也就是只要數據更改,(肯定要先有 log) 所有 DBWR,在數據文件上的修改
都會被先一步記入重做日誌文件,實例重啟後,SMON 進程再根據重做日誌文件來回滾。
其實 smon 的前滾回滾是根據檢查點來完成的,當一個全部檢查點發生的時候,首先讓 LGWR 進程將
redo log buffer 中的所有緩沖(包含未提交的重做信息)寫入重做日誌文件,然後讓 dbwr 進程將 db buffer 已
提交的緩沖寫入數據文件(不強制寫未提交的)。然後更新控制文件和數據文件頭部的 SCN,表明當前資料庫
是一致的,在相鄰的兩個檢查點之間有很多事務,有提交和未提交的。
像前面的前滾回滾比較完整的說法是如下的說明:
A.發生檢查點之前斷電,並且當時有一個未提交的改變正在進行,實例重啟之後,SMON 進程將從上一個
檢查點開始核對這個檢查點之後記錄在重做日誌文件中已提交的和未提交改變,因為
dbwr 之前會觸發 lgwr,所以 dbwr 對數據文件的修改一定會被先記錄在重做日誌文件中。因此,斷電前被
DBWN 寫進數據文件的改變將通過重做日誌文件中的記錄進行還原,叫做回滾,
B. 如果斷電時有一個已提交,但 dbwr 動作還沒有完全完成的改變存在,因為已經提交,提交會觸發 lgwr
進程,所以不管 dbwr 動作是否已完成,該語句將要影響的行及其產生的結果一定已經記錄在重做日誌文件中
了,則實例重啟後,SMON 進程根據重做日誌文件進行前滾.
實例失敗後用於恢復的時間由兩個檢查點之間的間隔大小來決定,可以通個四個參數設置檢查點執行的頻
率:
Log_checkpoint_interval:
決定兩個檢查點之間寫入重做日誌文件的系統物理塊(redo blocks)
的大小,默認值是 0,無限制。
log_checkpoint_timeout:
兩 個 檢 查 點 之 間 的 時 間 長 度（秒）默 認 值 1800s。
fast_start_io_target:
決定了用於恢復時需要處理的塊的多少,默認值是 0,無限制。
fast_start_mttr_target:
直接決定了用於恢復的時間的長短,默認值是 0,無限制(SMON 進程執行的前滾
和回滾與用戶的回滾是不同的,SMON 是根據重做日誌文件進行前滾或回滾,而用戶的回滾一定是根據回滾段
的內容進行回滾的。
在這里要說一下回滾段存儲的數據,假如是 delete 操作,則回滾段將會記錄整個行的數據,假如是 update,
則回滾段只記錄被修改了的欄位的變化前的數據(前映像),也就是沒有被修改的欄位是不會被記錄的,假如是
insert,則回滾段只記錄插入記錄的 rowid。 這樣假如事務提交,那回滾段中簡單標記該事務已經提交;假如是
回退,則如果操作是 delete,回退的時候把回滾段中數據重新寫回數據塊,操作如果是 update,則把變化前數據
修改回去,操作如果是 insert,則根據記錄的 rowid 把該記錄刪除。
2.如果用戶 rollback。
則伺服器進程會根據數據文件塊和 DB BUFFER 中塊的頭部的事務列表和 SCN 以及回滾段地址找到
回滾段中相應的修改前的副本,並且用這些原值來還原當前數據文件中已修改但未提交的改變。如果有多個
「前映像」,伺服器進程會在一個「前映像」的頭部找到「前前映像」的回滾段地址,一直找到同一事務下的最早的
一個「前映像」為止。一旦發出了 COMMIT,用戶就不能rollback,這使得 COMMIT 後 DBWR 進程還沒有
全部完成的後續動作得到了保障。到現在為例一個事務已經結束了。
說明:
TM 鎖:
符合 lock 機制的,用於保護對象的定義不被修改。 TX 鎖:
這個鎖代表一個事務,是行
級鎖,用數據塊頭、數據記錄頭的一些欄位表示,也是符合 lock 機制,有 resource structure、lock
structure、enqueue 演算法。
6. 在VB中，怎樣對SQL進行事務處理
事務處理是在數據處理時經常遇到的問題，經常用到的方法有以下3種總結整理如下：
方法1：直接寫入到sql中
在存儲過程中使用BEGINTRANS,COMMITTRANS,ROLLBACKTRANS實現
begintrans
declare@orderDetailsErrorint,@procuntErrorint
deletefrom[orderdetails]whereproctid=42
select@orderDetailsError=@@error
deletefromproctswhereproctid=42
select@procuntError=@@error
if(@orderDetailsError=0and@procuntError=0)
COMMITTRANS
else
ROLLBACKTRANS
優點：
所有事務邏輯包含在一個單獨的調用中
擁有運行一個事務的最佳性能
獨立於應用程序
限制：
事務上下文僅存在於資料庫調用中
資料庫代碼與資料庫系統有關
方法2：使用ADO.NET實現
使用ADO.NET實現，使用這種方式的優點是可以在中間層來管理事務，當然你也可以選擇在數據層來實現。
SqlConnection和OleDbConnection對象有一個BeginTransaction方法，它可以返回SqlTransaction
或者OleDbTransaction對象。而且這個對象有Commit和Rollback方法來管理事務
SqlConnectionsqlConnection=newSqlConnection("workstationid=WEIXIAOPING;packetsize=4096;userid=sa;initialcatalog=Northwind;persistsecurityinfo=False");
sqlConnection.Open();
SqlTransactionmyTrans=sqlConnection.BeginTransaction();
SqlCommandsqlInsertCommand=newSqlCommand();
sqlInsertCommand.Connection=sqlConnection
sqlInsertCommand.Transaction=myTrans;
try{
sqlInsertCommand.CommandText="insertintotbTree(Context,ParentID)values('北京',1)";
sqlInsertCommand.ExecuteNonQuery();
sqlInsertCommand.CommandText="insertintotbTree(Context,ParentID)values('上海',1)";
sqlInsertCommand.ExecuteNonQuery();
myTrans.Commit();
}catch(Exceptionex)
{
myTrans.Rollback();
}
finally
{
sqlConnection.Close();
}
優點:
簡單性
和數據據事務差不多的快
獨立於資料庫，不同資料庫的專有代碼被隱藏了
缺點:
事務不能跨越多個資料庫連接
事務執行在資料庫連接層上，所以需要在事務過程中維護一個資料庫連接
ADO.NET分布事務也可以跨越多個資料庫，但是其中一個SQLSERVER資料庫的話，通過用SQLSERVER連接伺服器連接到別的資料庫，但是如果是在DB2和Orcal之間就不可以。
以上兩種事務是經常用到的事務處理方法。
方法3COM+事務（分布式事務）
.NETFramework依靠MTS/COM+服務來支持自動事務。COM+使用(DTC)作為事務管理器和事務協調器在分布式環境中運行事務。
這樣可使.NET應用程序運行跨多個資源結合不同操作（例如，將定單插入SQLServer資料庫、將消息寫入Microsoft消息隊列(MSMQ)隊列、以及從Oracle資料庫檢索數據）
的事務。
COM+事務處理的類必須繼承System.EnterpriseServices.ServicedComponent，其實webservice就是繼承System.EnterpriseServices.ServicedComponent，所以webservice也支持
COM+事務。
定義一個COM+事務處理的類
[Transaction(TransactionOption.Required)]
publicclassDataAccess:System.EnterpriseServices.ServicedComponent
{
}
TransactionOption枚舉類型支持5個COM+值（Disabled,NotSupported,Required,RequiresNew,Supported）
Disabled忽略當前上下文中的任何事務。
NotSupported使用非受控事務在上下文中創建組件。
Required如果事務存在則共享事務，並且如有必要則創建新事務。
RequiresNew使用新事務創建組件，而與當前上下文的狀態無關。
Supported如果事務存在，則共享該事務。
一般來說COM+中的組件需要Required或Supported。當組件用於記錄或查帳時RequiresNew很有用，因為組件應該與活動中其他事務處理的提交或回滾隔離開來。
派生類可以重載基類的任意屬性。如DataAccess選用Required，派生類仍然可以重載並指定RequiresNew或其他值。
COM+事務有手動處理和自動處理，自動處理就是在所需要自動處理的方法前加上[AutoComplete]，根據方法的正常或拋出異常決定提交或回滾。
手動處理就是調用ContextUtil類中EnableCommit，SetComplete，SetAbort方法。
publicstringtestTransaction()
{
try
{
ContextUtil.EnableCommit();
InsertARecord1();
InsertARecord2();
ContextUtil.SetComplete();
return"succeed!";
}
catch(Exceptionex)
{
ContextUtil.SetAbort();
return"failed!";
}
}
publicvoidInsertARecord1()
{
stringstrconn="workstationid=WEIXIAOPING;packetsize=4096;userid=sa;initialcatalog=Northwind;persistsecurityinfo=False";
SqlConnectionconn=newSqlConnection(strconn);
conn.Open();
SqlCommandcommand=newSqlCommand("insertintotbTree(Context,ParentID)values('北京',1)",conn);
command.ExecuteNonQuery();
conn.Close();
}
publicvoidInsertARecord2()
{
stringstrconn="workstationid=WEIXIAOPING;packetsize=4096;userid=sa;initialcatalog=Northwind;persistsecurityinfo=False";
SqlConnectionconn=newSqlConnection(strconn);
conn.Open();
SqlCommandcommand=newSqlCommand("insertintotbTree(Context,ParentID)values('上海',1)",conn);
command.ExecuteNonQuery();
conn.Close();
}
在需要事務跨MSMQ和其他可識別事務的資源（例如，SQLServer資料庫）運行的系統中，只能使用DTC或COM+事務，除此之外沒有其他選擇。DTC協調參與分布式事務的所有資源管理器， 也管理與事務相關的操作。
這種做法的缺點是，由於存在DTC和COM互操作性開銷，導致性能降低。
COM+事務處理的類必須強命名。
7. 如何優化mysql寫入速
單機MySQL資料庫的優化
一、伺服器硬體對MySQL性能的影響
①磁碟尋道能力 （磁碟I/O），我們現在上的都是SAS15000轉的硬碟。MySQL每秒鍾都在進行大量、復雜的查詢操作，對磁碟的讀寫量可想而知。所以，通常認為磁 盤I/O是制約MySQL性能的最大因素之一，對於日均訪 問量在100萬PV以上的Discuz!論壇，由於磁碟I/O的制約，MySQL的性能會非常低下！解決這一制約因素可以考慮以下幾種解決方案： 使用RAID1+0磁碟陣列，注意不要嘗試使用RAID-5，MySQL在RAID-5磁碟陣列上的效率不會像你期待的那樣快。
②CPU 對於MySQL應用，推薦使用DELL R710，E5620 @2.40GHz（4 core）* 2 ，我現在比較喜歡DELL R710，也在用其作Linuxakg 虛擬化應用；
③物理內存對於一台使用MySQL的Database Server來說，伺服器內存建議不要小於2GB，推薦使用4GB以上的物理內存，不過內存對於現在的伺服器而言可以說是一個可以忽略的問題，工作中遇到高端伺服器基本上內存都超過了32G。
我們工作中用得比較多的資料庫伺服器是HP DL580G5和DELL R710，穩定性和性能都不錯；特別是DELL R710，我發現許多同行都是採用它作資料庫的伺服器，所以重點推薦下。
二、MySQL的線上安裝我建議採取編譯安裝的方法，這樣性能上有較大提升，伺服器系統我建議用64bit的Centos5.5，源碼包的編譯參數會默 認以Debgu模式生成二進制代碼，而Debug模式給MySQL帶來的性能損失是比較大的，所以當我們編譯准備安裝的產品代碼時，一定不要忘記使用「— without-debug」參數禁用Debug模式。而如果把—with-mysqld-ldflags和—with-client-ldflags二 個編譯參數設置為—all-static的話，可以告訴編譯器以靜態方式編譯和編譯結果代碼得到最高的性能。使用靜態編譯和使用動態編譯的代碼相比，性能 差距可能會達到5%至10%之多。我參考了簡朝陽先生的編譯參數，特列如下，供大家參考
./configure –prefix=/usr/local/mysql –without-debug –without-bench –enable-thread-safe-client –enable-assembler –enable-profiling –with-mysqld-ldflags=-all-static –with-client-ldflags=-all-static –with-charset=latin1 –with-extra-charset=utf8,gbk –with-innodb –with-csv-storage-engine –with-federated-storage-engine –with-mysqld-user=mysql –without-我是怎麼了ded-server –with-server-suffix=-community –with-unix-socket-path=/usr/local/mysql/sock/mysql.sock
三、MySQL自身因素當解決了上述伺服器硬體制約因素後，讓我們看看MySQL自身的優化是如何操作的。對 MySQL自身的優化主要是對其配置文件my.cnf中的各項參數進行優化調整。下面介紹一些對性能影響較大的參數。
下面，根據以上硬體配置結合一份已經優化好的my.cnf進行說明：
#vim /etc/my.cnf
以下只列出my.cnf文件中[mysqld]段落中的內容，其他段落內容對MySQL運行性能影響甚微，因而姑且忽略。
[mysqld]
port = 3306
serverid = 1
socket = /tmp/mysql.sock
skip-locking
#避免MySQL的外部鎖定，減少出錯幾率增強穩定性。
skip-name-resolve
#禁止MySQL對外部連接進行DNS解析，使用這一選項可以消除MySQL進行DNS解析的時間。但需要注意，如果開啟該選項，則所有遠程主機連接授權都要使用IP地址方式，否則MySQL將無法正常處理連接請求！
back_log = 384
#back_log參數的值指出在MySQL暫時停止響應新請求之前的短時間內多少個請求可以被存在堆棧中。 如果系統在一個短時間內有很多連接，則需要增大該參數的值，該參數值指定到來的TCP/IP連接的偵聽隊列的大小。不同的操作系統在這個隊列大小上有它自 己的限制。 試圖設定back_log高於你的操作系統的限制將是無效的。默認值為50。對於Linux系統推薦設置為小於512的整數。
key_buffer_size = 384M
#key_buffer_size指定用於索引的緩沖區大小，增加它可得到更好的索引處理性能。對於內存在4GB左右的伺服器該參數可設置為256M或384M。注意：該參數值設置的過大反而會是伺服器整體效率降低！
max_allowed_packet = 4M
thread_stack = 256K
table_cache = 614K
sort_buffer_size = 6M
#查詢排序時所能使用的緩沖區大小。注意：該參數對應的分配內存是每連接獨占，如果有100個連接，那麼實際分配的總共排序緩沖區大小為100 × 6 ＝ 600MB。所以，對於內存在4GB左右的伺服器推薦設置為6-8M。
read_buffer_size = 4M
#讀查詢操作所能使用的緩沖區大小。和sort_buffer_size一樣，該參數對應的分配內存也是每連接獨享。
join_buffer_size = 8M
#聯合查詢操作所能使用的緩沖區大小，和sort_buffer_size一樣，該參數對應的分配內存也是每連接獨享。
myisam_sort_buffer_size = 64M
table_cache = 512
thread_cache_size = 64
query_cache_size = 64M
#指定MySQL查詢緩沖區的大小。可以通過在MySQL控制台觀察，如果Qcache_lowmem_prunes的值非常大，則表明經常出現緩沖不 夠 的情況；如果Qcache_hits的值非常大，則表明查詢緩沖使用非常頻繁，如果該值較小反而會影響效率，那麼可以考慮不用查詢緩 沖；Qcache_free_blocks，如果該值非常大，則表明緩沖區中碎片很多。
tmp_table_size = 256M
max_connections = 768
#指定MySQL允許的最大連接進程數。如果在訪問論壇時經常出現Too Many Connections的錯誤提 示，則需要增大該參數值。
max_connect_errors = 1000
wait_timeout = 10
#指定一個請求的最大連接時間，對於4GB左右內存的伺服器可以設置為5-10。
thread_concurrency = 8
#該參數取值為伺服器邏輯CPU數量*2，在本例中，伺服器有2顆物理CPU，而每顆物理CPU又支持H.T超線程，所以實際取值為4*2=8；這個目前也是雙四核主流伺服器配置。
skip-networking
#開啟該選項可以徹底關閉MySQL的TCP/IP連接方式，如果WEB伺服器是以遠程連接的方式訪問MySQL資料庫伺服器則不要開啟該選項！否則將無法正常連接！
table_cache=1024
#物理內存越大，設置就越大。默認為2402,調到512-1024最佳
innodb_additional_mem_pool_size=4M
#默認為2M
innodb_flush_log_at_trx_commit=1
#設置為0就是等到innodb_log_buffer_size列隊滿後再統一儲存，默認為1
innodb_log_buffer_size=2M
#默認為1M
innodb_thread_concurrency=8
#你的伺服器CPU有幾個就設置為幾，建議用默認一般為8
key_buffer_size=256M
#默認為218，調到128最佳
tmp_table_size=64M
#默認為16M，調到64-256最掛
read_buffer_size=4M
#默認為64K
read_rnd_buffer_size=16M
#默認為256K
sort_buffer_size=32M
#默認為256K
thread_cache_size=120
#默認為60
query_cache_size=32M
※值得注意的是：
很多情況需要具體情況具體分析
一、如果Key_reads太大，則應該把my.cnf中Key_buffer_size變大，保持Key_reads/Key_read_requests至少1/100以上，越小越好。
二、如果Qcache_lowmem_prunes很大，就要增加Query_cache_size的值。
很多時候我們發現，通過參數設置進行性能優化所帶來的性能提升，可能並不如許多人想像的那樣產生質的飛躍，除非是之前的設置存在嚴重不合理的情況。我們 不能將性能調優完全依託於通過DBA在資料庫上線後進行的參數調整，而應該在系統設計和開發階段就盡可能減少性能問題。
【51CTO獨家特稿】如果單MySQL的優化始終還是頂不住壓力時，這個時候我們就必須考慮MySQL的高可用架構（很多同學也愛說成是MySQL集群）了，目前可行的方案有：
一、MySQL Cluster
優勢：可用性非常高，性能非常好。每份數據至少可在不同主機存一份拷貝，且冗餘數據拷貝實時同步。但它的維護非常復雜，存在部分Bug，目前還不適合比較核心的線上系統，所以這個我不推薦。
二、DRBD磁碟網路鏡像方案
優勢：軟體功能強大，數據可在底層快設備級別跨物理主機鏡像，且可根據性能和可靠性要求配置不同級別的同步。IO操作保持順序，可滿足資料庫對數據一致 性的苛刻要求。但非分布式文件系統環境無法支持鏡像數據同時可見，性能和可靠性兩者相互矛盾，無法適用於性能和可靠性要求都比較苛刻的環境，維護成本高於 MySQL Replication。另外，DRBD也是官方推薦的可用於MySQL高可用方案之一，所以這個大家可根據實際環境來考慮是否部署。
三、MySQL Replication
在實際應用場景中，MySQL Replication是使用最為廣泛的一種提高系統擴展性的設計手段。眾多的MySQL使用者通過Replication功能提升系統的擴展性後，通過 簡單的增加價格低廉的硬體設備成倍 甚至成數量級地提高了原有系統的性能，是廣大MySQL中低端使用者非常喜歡的功能之一，也是許多MySQL使用者選擇MySQL最為重要的原因。
比較常規的MySQL Replication架構也有好幾種，這里分別簡單說明下
MySQL Replication架構一：常規復制架構--Master-slaves，是由一個Master復制到一個或多個Salve的架構模式，主要用於讀壓力大的應用資料庫端廉價擴展解決方案，讀寫分離，Master主要負責寫方面的壓力。
MySQL Replication架構二：級聯復制架構，即Master-Slaves-Slaves,這個也是為了防止Slaves的讀壓力過大，而配置一層二級 Slaves，很容易解決Master端因為附屬slave太多而成為瓶勁的風險。
MySQL Replication架構三：Dual Master與級聯復制結合架構，即Master-Master-Slaves，最大的好處是既可以避免主Master的寫操作受到Slave集群的復制帶來的影響，而且保證了主Master的單點故障。
以上就是比較常見的MySQL replication架構方案，大家可根據自己公司的具體環境來設計 ，Mysql 負載均衡可考慮用LVS或Haproxy來做，高可用HA軟體我推薦Heartbeat。
MySQL Replication的不足：如果Master主機硬體故障無法恢復，則可能造成部分未傳送到slave端的數據丟失。所以大家應該根據自己目前的網路 規劃，選擇自己合理的Mysql架構方案，跟自己的MySQL DBA和程序員多溝涌，多備份（備份我至少會做到本地和異地雙備份），多測試，數據的事是最大的事，出不得半點差錯，切記切記。
8. SQL中事務有什麼好處 如何使用事務
事務的好處在於，當你需要對多個表進行相關性操作時，使用BeginTrans()開啟事務，然後操作，如果中間哪個表更新出錯了，或者數據有問題，你可以用RollBack()方法在取消之前的相關性操作，如果沒有錯，那就使用Commit()方法提交你的修改。另外，在這個過程中，所有你改動的內容只對你自己有效，別人不能知道你改了什麼，也不能對你正在改的表做修改，直到你提交之後，別人才能修改這些表，檢索出你修改過的內容。