當前位置:首頁 » 編程語言 » sql中的回滾
擴展閱讀
webinf下怎麼引入js 2023-08-31 21:54:13
堡壘機怎麼打開web 2023-08-31 21:54:11

sql中的回滾

發布時間: 2022-06-25 21:28:49

『壹』 sql語言中,用於事務回滾的語句是什麼

回滾要放在事務裡面進行,才能進行回滾;sql裡面的事務使用關鍵字TransAction
1:可以用try catch捕獲
begin try
begin tran
update table set a=1;
commit tran
end Try
begin catch
rollback tran
end catch

2:可以使用error 全局變數
begin tran
update tablename set ad=1111
if @@error<>0 begin rollback end
commit tran

注意:如果一個事務寫了 begin trans ,後面一定要跟上 commit tran或 rollback transaction ,否則可能導致被鎖

『貳』 關於sql中的事務回滾問題 ,就是commit 和 rollback的順序問題

begin
try

end
try捕獲產生的錯誤
然後在begin
catch

end
catch
塊中使用rollback語句讓事務回滾
你可以簡單地先寫個小例子試一下,體會下rollback的用法
比如:
begin
tran
update
table2
set
b=10,c=10
where
a=1
rollback
tran
就會發現數據沒有被更新
然後再結合begin
try
end
try
begin
catch
end
catch的用法
就能實現在事務執行過程中出錯後回滾的功能
大概的形式就是這樣:
begin
tran
begin
try
--做相關操作
--結束的時候如果沒有錯誤則用commit提交事務
commit
tran
end
try
begin
catch
--出現錯誤的時候會跳轉到這里
--用rollback回滾事務
rollback
tran
end
catch

『叄』 SQL語句如何rollback

rollback是針對事務的,你如果沒有在執行語句之前開啟事務,那麼無法rollback,建議你還是想別的辦法吧,事務語句如下(sqlserver的給你借鑒):
--開啟事務
begin tran
--執行操作
update Accounts_UsersExp set TelPhone=123456 where userid=14
--執行錯誤事務回滾
rollback
--如果正確進行事務提交
commit
可以勾選一句執行一句,但是commit了就不能rollback

『肆』 SQL 觸發器中事物回滾什麼意思

當事物裡面的執行語句發生錯誤或者異常時Rollback,撤銷錯誤前執行的操作。

『伍』 對於已經執行成功的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 語句回滾的問題幫幫忙。

用事務處理(比如事務名稱是UpdatePrintBill,可以隨便起名稱)
BEGIN
TRANSACTION
UpdatePrintBill
--中間寫你的代碼
insert
into
T_BHS_OrderList(OrderList_OrderNum,OrderList_ProId,
OrderList_ProName,OrderList_Pubish_Id,OrderList_SortId,
OrderList_UserID,OrderList_Price,OrderList_Count,
OrderList_CommonPrice,OrderList_Down,OrderList_Time)
select
@OrderNumber,Cart_ProId,Cart_ProName,Cart_Pubish_Id,Cart_Status,Cart_UserId,
Cart_Price,Cart_Count,Cart_CommonPrice,Cart_Down,getdate()
from
dbo.T_BHS_Cart
where
Cart_UserId=@userID
--結束你的代碼
IF
@@ERROR
>
0
BEGIN
rollback
TRANSACTION
UpdatePrintBill
return
-1
END
else
begin
COMMIT
TRANSACTION
UpdatePrintBill
return
1
end

『柒』 SQL資料庫,能進行回滾操作么

回滾操作時有前提的
得開事物才行
如果默認
就自動commit了
如果是工具操作的
應該有回滾按鈕

『捌』 高斯誤執行sql怎麼回滾

回滾指的是在一個SQL事務中,如果遇到執行報錯等情況,可以回滾到事務開始的地方。『
但是如果語句已經執行完畢,那麼是沒有類似於word中撤銷的功能,只能找到語句執行之前資料庫的備份,通過關聯表查詢去找到修改前的記錄

『玖』 sql 回滾語句

事務回滾Transaction Rollback 是指當事務中的某一語句執行失敗時將對資料庫
的操作恢復到事務執行前或某個指定位置.
如:
begin transaction my_transaction_delete
use pangu
go
delete from department
where dept_id = 』1012』
update employee
set dept_id = 』1001』
where dept_id = 』1012』
if @@error!=0 or @@rowcount=0 then
begin
rollback tran after_delete /* 回滾到保存點after_deletereturn,如果使用rollback my_transaction_delete 則會回滾到事務開始前 */
commit tran
print 『更新員工信息表時產生錯誤』
return
end
commit transaction my_transaction_delete
go