㈠ 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命令，如何回滾
當啟動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 事務自動回滾
你要用SET XACT_ABORT (Transact-SQL)
指定當 Transact-SQL 語句出現運行時錯誤時，SQL Server 是否自動回滾到當前事務。
當 SET XACT_ABORT 為 ON 時，如果執行 Transact-SQL 語句產生運行時錯誤，則整個事務將終止並回滾。
當 SET XACT_ABORT 為 OFF 時，有時只回滾產生錯誤的 Transact-SQL 語句，而事務將繼續進行處理。如果錯誤很嚴重，那麼即使 SET XACT_ABORT 為 OFF，也可能回滾整個事務。OFF 是默認設置。
編譯錯誤（如語法錯誤）不受 SET XACT_ABORT 的影響。
㈣ sql server事務回滾代碼怎麼寫
事務回滾有幾種，下面只是常見的一種
declare@iErrorCountint
set@iErrorCount=0
begintranTran1
insertintot1(Id,c1)values(1,'1')
set@iErrorCount=@iErrorCount+@@error
insertintot1(Id,c1)values('XX2','2')
set@iErrorCount=@iErrorCount+@@error
if@iErrorCount=0
begin
COMMITTRANTran1--執行事務
end
else
begin
ROLLBACKTRANTran1--回滾事務
end
㈤ SQL資料庫中事務回滾會影響性能嗎
首先性能肯定受影響，因為要反向回滾操作。
以sqlserver為例，如果是插入操作，回滾期間鎖表，而且一般級別資料庫消耗時間接近1:3。如果插入進行了1小時有可能要超過3小時多來完成回滾，此時不要強行關閉資料庫或者殺死進程，也為無論如何為了保持acid特性也不會中止回滾只能等。
㈥ 資料庫（sql server ）回滾事務
這個要求不需要用事務回滾的吧。
insert
中加上判斷該工號記錄數的條件即可，保證當記錄數少於4時執行插入語句。
insert
（）
values（）
where（select
count（*）
from
table
where
emp_id=『20100021』）<4
㈦ 關於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
㈧ 什麼是事務事務中的提交和回滾是什麼意思
事務（Transaction），一般是指要做的或所做的事情。在計算機術語中是指訪問並可能更新資料庫中各種數據項的一個程序執行單元(unit)。事務通常由高級資料庫操縱語言或編程語言（如SQL，C++或Java）書寫的用戶程序的執行所引起，並用形如begin transaction和end transaction語句（或函數調用）來界定。
事務的提交是指事務里的所有操作都正常完成。
事務的回滾是指程序或數據處理錯誤，將程序或數據恢復到上一次正確狀態的行為。
(8)sql2008事務回滾擴展閱讀：
事務的特徵：
事務應該具有4個屬性：原子性、一致性、隔離性、持久性。這四個屬性通常稱為ACID特性。
1、原子性（atomicity）。一個事務是一個不可分割的工作單位，事務中包括的諸操作要麼都做，要麼都不做。
2、一致性（consistency）。事務必須是使資料庫從一個一致性狀態變到另一個一致性狀態。一致性與原子性是密切相關的。
隔離性（isolation）。一個事務的執行不能被其他事務干擾。即一個事務內部的操作及使用的數據對並發的其他事務是隔離的，並發執行的各個事務之間不能互相干擾。
4、持久性（rability）。持久性也稱永久性（permanence），指一個事務一旦提交，它對資料庫中數據的改變就應該是永久性的。接下來的其他操作或故障不應該對其有任何影響。
㈨ sql語句中用什麼語句實現事務的回滾
-開啟事務 begin tran --執行操作 update Accounts_UsersExp set TelPhone=123456 where userid=14 --執行錯誤事務回滾 rollback --如果正確進行事務提交 commit
㈩ sql server 事務回滾
在程序中可以使用try{//提交事物}catch(Exception e){//回滾事物}。只要是通過事物來提交的命令，都可以回滾。