SQL命令回滾

㈠ 資料庫中前滾、回滾什麼意思

前滾是將未完成的操作繼續完成，回滾是將執行完的操作回復過來

㈡ sql基本命令都是什麼含義，求列表解釋

SQL基本命令涵蓋數據定義、數據操縱、事務控制和數據控制，每個部分詳細列舉了具體的命令及其作用。數據定義語言中，Create用於創建新表，Alter用於修改現有表結構，Drop用於刪除表。數據操縱語言包括Insert用於向表中添加記錄，Select用於查詢表中的數據，Delete用於刪除表中的記錄，Update用於修改表中記錄的值。事務控制語言中的Commit用於提交事務，Savepoint用於設置事務中的保存點，Rollback用於回滾事務。數據控制語言則包括Grant用於授予用戶許可權，Revoke用於回收用戶許可權。

字元數據類型包括Char、Varchar2和Long，其中Char長度固定，Varchar2長度可變，Long最大可存儲2GB。數值數據類型為Number，支持正數、負數、零、定點數和浮點數。日期時間數據類型有Date和Timestamp，其中Date使用固定長度存儲，Timestamp包括時間精度到小數點後6位，還支持時區信息。Raw和LongRaw用於存儲二進制數據，Raw最大2000位元組，LongRaw最大2GB。LOB包括Clob、Blob和Bfile，用於存儲大量文本和二進制數據，Clob和Blob存儲非結構化數據，Bfile存儲文件路徑。

在創建表時，如Create table Cool(Cool_ID number, Cool_Name varchar(20), Cool_like varchar(30))，插入數據使用Insert into Cool values(8850,'酷兒','編寫Java應用程序')。更新表中的數據，如Update cool set cool_name='酷兒至酷' where cool_name='酷兒'。刪除數據使用Delete cool where cool_like='編寫Java應用程序null'。使用Select * from emp查詢所有數據，Select * from emp where ename='adams'按條件查詢，Select distinct * from emp不選擇重復行。排序使用Select * from cool where cool_name='酷兒' order by cool_id asc。

事務控制中，Commit提交事務，Rollback回滾事務，Savepoint設置事務保存點。數據控制語言包括Grant和Revoke，如Grant select,update,delete on cool to hedong911。通過Select語句可以使用各種比較和邏輯操作符，如Select * from cool where cool_name like '酷兒'。集合操作符如Union、Union all、Intersect和Minus用於聯合查詢。

SQL的||操作符用於連接字元串，如Select ('用戶編號:'||cool_id||'姓名是:'||cool_name||'愛好是:'||cool_like||'日期是:'||cool_date) from cool where cool_id=8859。這些命令共同構成了SQL語言的核心，幫助資料庫管理員和開發人員高效管理數據。

㈢ 對於已經執行成功的sql命令，如何回滾

當啟動Binlog後，事務會產生Binlog Event，這些Event被看做事務數據的一部分。因此要保證事務的Binlog Event和InnoDB引擎中的數據的一致性。所以帶Binlog的CrashSafe要求MySQL宕機重啟後能夠保證：

- 所有已經提交的事務的數據仍然存在。

- 所有沒有提交的事務的數據自動回滾。

- 所有已經提交了的事務的Binlog Event也仍然存在。

- 所有沒有提交事務沒有記錄Binlog Event。

這些要求很好理解，如果重啟後數據還在，但是Binlog Event沒有了，就沒辦法復制到其他節點上了。如果重啟後，數據沒了，但是Binlog Event還在，那麼不存在的數據就會被復制到其他節點上，從而導致主從的不一致。

為了保證帶Binlog的CrashSafe，MySQL內部使用的兩階段提交(Two Phase Commit)。

2 - MySQL的Two Phase Commit(2PC)

在開啟Binlog後，MySQL內部會自動將普通事務當做一個XA事務來處理：
- 自動為每個事務分配一個唯一的ID
- COMMIT會被自動的分成Prepare和Commit兩個階段。
- Binlog會被當做事務協調者(Transaction Coordinator)，Binlog Event會被當做協調者日誌。
想了解2PC，可以參考文檔：【https://en.wikipedia.org/wiki/Two-phase_commit_protocol。】

- 分布式事務ID(XID)

使用2PC時，MySQL會自動的為每一個事務分配一個ID，叫XID。XID是唯一的，每個事務的XID都不相同。XID會分別被Binlog和InnoDB記入日誌中，供恢復時使用。MySQ內部的XID由三部分組成：

- 前綴部分

前綴部分是字元串"MySQLXid"

- Server ID部分

當前MySQL的server_id
- query_id部分

為了保證XID的的唯一性，數字部分使用了query_id。MySQL內部會自動的為每一個語句分配一個query_id，全局唯一。

參考代碼：sql/xa。h的struct xid_t結構。

- 事務的協調者Binlog

Binlog在2PC中充當了事務的協調者（Transaction Coordinator）。由Binlog來通知InnoDB引擎來執行prepare，commit或者rollback的步驟。事務提交的整個過程如下：

1. 協調者准備階段(Prepare Phase)

告訴引擎做Prepare，InnoDB更改事務狀態，並將Redo Log刷入磁碟。

2. 協調者提交階段(Commit Phase)

2.1 記錄協調者日誌，即Binlog日誌。

2.2 告訴引擎做commit。
注意：記錄Binlog是在InnoDB引擎Prepare(即Redo Log寫入磁碟)之後，這點至關重要。

在MySQ的代碼中將協調者叫做tc_log。在MySQL啟動時，tc_log將被初始化為mysql_bin_log對象。參考sql/binlog.cc中的init_server_components()：
if (opt_bin_log) tc_log= &mysql_bin_log;

而在事務提交時，會依次執行：
tc_log->prepare()；
tc_log->commit()；
參考代碼：sql/binlog.cc中的ha_commit_trans()。當mysql_bin_log是tc_log時，prepare和commit的代碼在sql/binlog.cc中：

MYSQL_BIN_LOG::prepare()；
MYSQL_BIN_LOG::commit()；

-協調者日誌Xid_log_event
作為協調者，Binlog需要將事務的XID記入日誌，供恢復時使用。Xid_log_event有以下幾個特點：
- 僅記錄query_id
因為前綴部分不變，server_id已經記錄在Event Header中，Xid_log_event中只記錄query_id部分。
- 標志事務的結束

在Binlog中相當於一個事務的COMMIT語句。

一個事務在Binlog中看起來時這樣的：
Query_log_event("BEGIN");DML產生的events; Xid_log_event;

- DDL沒有BEGIN，也沒有Xid_log_event 。
- 僅InnoDB的DML會產生Xid_log_event
因為MyISAM不支持2PC所以不能用Xid_log_event ，但會有COMMIT Event。
Query_log_event("BEGIN");DML產生的events;Query_log_event("COMMIT");

問題：Query_log_event("COMMIT")和Xid_log_event 有不同的影響嗎？

- Xid_log_event 中的Xid可以幫助master實現CrashSafe。
- Slave的CrashSafe不依賴Xid_log_event
事務在Slave上重做時，會重新產生XID。所以Slave伺服器的CrashSafe並不依賴於Xid_log_event 。Xid_log_event 和Query_log_event("COMMIT")，只是作為事務的結尾，告訴Slave Applier去提交這個事務。因此二者在Slave上的影響是一樣的。

3 - 恢復(Recovery)
這個機制是如何保證MySQL的CrashSafe的呢，我們來分析一下。這里我們假設用戶設置了以下參數來保證可靠性：

- 恢復前事務的狀態
在恢復開始前事務有以下幾種狀態：
- InnoDB中已經提交
根據前面2PC的過程，可知Binlog中也一定記錄了該事務的的Events。所以這種事務是一致的不需要處理。
- InnoDB中是prepared狀態，Binlog中有該事務的Events。
需要通知InnoDB提交這些事務。
- InnoDB中是prepared狀態，Binlog中沒有該事務的Events。
因為Binlog還沒記錄，需要通知InnoDB回滾這些事務。
- Before InnoDB Prepare
事務可能還沒執行完，因此InnoDB中的狀態還沒有prepare。根據2PC的過程，Binlog中也沒有該事務的events。 需要通知InnoDB回滾這些事務。

- 恢復過程
從上面的事務狀態可以看出：恢復時事務要提交還是回滾，是由Binlog來決定的。
- 事務的Xid_log_event 存在，就要提交。
- 事務的Xid_log_event 不存在，就要回滾。

恢復的過程非常簡單：
- 從Binlog中讀出所有的Xid_log_event
- 告訴InnoDB提交這些XID的事務
- InnoDB回滾其它的事務

㈣ sql中的存儲過程里怎麼寫事務回滾啊

CREATE PROC [dbo].[notice_Delete] --- 同時刪除該通知書和對應的節點
@tbl VARCHAR(30),
@pid INT
AS
BEGIN
DECLARE @tblname VARCHAR(30) ;
DECLARE @sql VARCHAR(1000) ;
SET @tblname = @tbl
SET @sql = 'delete ' + @tblname + ' where id ='
+ CONVERT(VARCHAR(10), @pid)

BEGIN TRAN --開始事務

EXEC ( @sql
)
IF ( @@rowcount = 0 ) --執行結果影響行數為0
BEGIN
ROLLBACK TRAN --回滾
END
ELSE
BEGIN
DELETE FROM tbl_treenotice
WHERE purposeid = @pid
IF ( @@rowcount = 0 ) --執行結果影響行數為0
BEGIN
ROLLBACK TRAN --回滾
END
ELSE
BEGIN
COMMIT TRAN --提交事務
END
END
END

㈤ sql存儲過程中事務出現錯誤回滾，那麼在回滾之後的語句會執行嗎

會的。

一般回滾操作都是寫在異常處理，或是sql的最後。如果你的sql中出現錯誤 ，代碼會立即跳轉到錯誤處理代碼上執行，比如回滾，但緊接在錯誤行之後的代碼不會執行的。

如
1.update .....;

2.select ......;
3.when Exception
....rollback;
4.insert into .....

以上偽代碼，如果行1出錯，行2將不會執行，直接跳轉到行3，然後行4 也會執行。