⑴ 資料庫中前滾、回滾什麼意思
資料庫中的undo、rollback，既撤消和回滾。首先這2個操作是針對事務來說的，事務的概念請樓主自行網路。
舉一個簡單的例子，A給B轉賬，在資料庫中就需要給A,B進行update操作。這2條sql語句必須都執行或者都不執行（稱為一個事務）。假如先執行B的update語句，B的金額增加了100，然後執行A的update語句，A的金額減100。如果A的余額大於100，那麼2個語句沒問題，但是A的余額小於100時，再減100就變成負的了，這不符合實際情況。所以第二條sql就出現無法執行，那麼資料庫的狀態必須回到沒有執行B的update語句之前。
當一個事務執行的時候，資料庫會依次執行中間的sql語句，當某一條sql發生錯誤以後，根據事務的原子性，通過2種方式使資料庫回到事務沒有執行的狀態。撤銷就是相當於不執行commit；回滾就是執行一遍相反的操作，比如再執行B的update金額減100。
⑵ sql server 中的update語句回滾怎麼寫啊
回滾要放在事務裡面進行，才能進行回滾；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 ，否則可能導致被鎖
⑶ mysql 能否設置DDL語句 可以回滾
MySQL8.0 開始支持原⼦ DDL(atomic DDL)，數據字典的更新，存儲引擎操作，寫⼆進制日誌結合成了一個事務。在沒有原⼦DDL之前，DROP TABLE test1,test2；如遇到server crash，可能會有test1被drop了，test2沒有被drop掉。下面來看下在MySQL8.0之前和MySQL8.0 數據字典的區別
在MySQL8.0 之前，Data Dictionary除了存在與.FRM, .TRG, .OPT ⽂件外，還存在於系統表中（MyISAM ⾮事務引擎表中），在MySQL8.0 ，Data Dictionary 全部存在於Data Dictionary Storage Engine（即 InnoDB表中），這使crash recovery 維持原⼦性成為了可能
存儲引擎⽀持
目前，只有InnoDB存儲引擎⽀持原子DDL，為了實現原子DDL，Innodb要寫DDL logs 到 mysql.innodb_ddl_log 表，這是⼀個隱藏在mysql.ibd 數據字典表空間⾥的數據字典表。要看mysql.innodb_ddl_log 中的內容，需要
SET GLOBALLOG_ERROR_VERBOSITY=3;（MySQL 8.0 默認為2，error log 記錄Errors and
warnings，不不記錄notes）
SET GLOBAL innodb_print_ddl_logs=1;
CREATE TABLEt1 (c1 INT)ENGINE=InnoDB;
查看error log
[Note] [MY-011066] InnoDB: DDL loginsert: [DDLrecord:DELETE SPACE,id=30,
thread_id=25, space_id=9, old_file_path=./test/t1.ibd]
[Note] [MY-011066]InnoDB:DDL logdelete:by id30
[Note] [MY-011066]InnoDB:DDL loginsert: [DDLrecord: REMOVECACHE,id=31,
thread_id=25, table_id=1066, new_file_path=test/t1]
[Note] [MY-011066]InnoDB:DDL logdelete:by id31
[Note] [MY-011066]InnoDB:DDL loginsert: [DDLrecord: FREE,id=32, thread_
id=25, space_id=9, index_id=143, page_no=4]
[Note] [MY-011066]InnoDB:DDL log delete:by id32
[Note] [MY-011066]InnoDB:DDL logpost ddl :begin for thread id: 25
[Note] [MY-011066]InnoDB:DDL logpost ddl :end for thread id: 25
原子DDL 操作步驟
准備：創建所需的對象並將DDL⽇志寫入 mysql.innodb_ddl_log表中。DDL日誌定義了如何前滾和回滾DDL操作。
執行：執⾏DDL操作。例如，為CREATE TABLE操作執⾏創建。
提交：更新數據字典並提交數據字典事務。
Post-DDL：重播並從mysql.innodb_ddl_log表格中刪除DDL⽇志。為確保回滾可以安全執⾏⽽不引⼊不⼀致性，在此最後階段執⾏⽂件操作（如重命名或刪除數據文件）。這一階段還從 mysql.innodb_dynamic_metadata的數據字典表刪除的動態元數據為了DROP TABLE，TRUNCATE和其它重建表的DDL操作。
⽆論事務是提交還是回滾，DDL日誌都會mysql.innodb_ddl_log在Post-DDL階段重播並從表中刪除 。mysql.innodb_ddl_log如果伺服器在DDL操作期間暫停，DDL⽇志應該只保留在表中。在這種情況下，DDL⽇志會在恢復後重播並刪除。
在恢復情況下，當伺服器重新啟動時，可能會提交或回退DDL事務。如果在重做⽇志和⼆進制日誌中存在DDL操作的提交階段期間執⾏的數據字典事務，則該操作被認為是成功的並且被前滾。否則，在InnoDB重放數據字典重做日誌時回滾不完整的數據字典事務 ，並且回滾DDL事務。
原⼦DDL ⽀持類型
• DROP TABLES , all tables dropped or none
• DROP SCHEMA, all entities in the schema are dropped, or none
• Note that atomic DDL statements will be rolled back or committed even in case of crash, e.g. RENAME TABLES
• CREATE TABLE would be successfully committed or rolled back (no orphan ibd left)
• TRUNCATE TABLE (including InnoDB tables with FTS AUX tables) would be successfully committed or rolled back
• RENAME TABLES, all or none
• ALTER TABLE successful or not done
示例
結論
在MySQL8.0之前，alter table 操作在server crash的情況下，會遺留.frm,.ibd文件。MySQL8.0 能實現原⼦DDL（包括 DROP TABLE, DROP SCHEMA, CREATE TABLE, TRUNCATE TABLE, ALTER TABLE），alter table 操作，在server crash的情況下，不會遺留.frm，.ibd臨時文件。讓我們⼀起期待MySQL8.0 GA的到來吧！
⑷ SQL語句如何rollback
回滾要放在事務裡面進行，才能進行回滾；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語言中,用於事務回滾的語句是什麼
回滾要放在事務裡面進行，才能進行回滾；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語句如何rollback
rollback是針對事務的，你如果沒有在執行語句之前開啟事務，那麼無法rollback，建議你還是想別的辦法吧，事務語句如下（sqlserver的給你借鑒）：
--開啟事務
begin tran
--執行操作
update Accounts_UsersExp set TelPhone=123456 where userid=14
--執行錯誤事務回滾
rollback
--如果正確進行事務提交
commit
可以勾選一句執行一句，但是commit了就不能rollback
⑺ Mysql insert 自增 id 表，如何進行回滾語句生成
兩個辦法。
第一是你批量插入的數據要麼全部成功，要麼全部失敗，不需要顧及部分成功的時候回滾存在所謂的誤刪。意思就是說(1,1),(2,2),(3,3) 三個插入，要不就都進去了，要不都不要進去；只要考慮直接rollback就行了；
第二個辦法是你自己控制寫入的主鍵值，維護一個主鍵的序列，每次插入之前先去序列裡面申請一個值，即使並發的時候也要這么做，從機器角度來講，真正在毫秒級別上的並發也能被識別出來；確保了每組寫入的主鍵不同，失敗的時候就知道到底是哪個主鍵對應的插入失敗了。就是類似於使用oracle的sequence值來做主鍵。
⑻ 資料庫的問題，事務定義中，COMMIT語句和ROLLBACK語句的作用是什麼
Commit表示提交。Rollback的意思是回滾。
甲骨文公司（是一家全球資料庫軟體公司，總部位於美國加州紅杉城。2008年，按收入計算，甲骨文公司是全球第三大軟體公司，僅次於微軟和IBM。
Oracle資料庫產品被財富榜上的前1000家公司使用，也被許多大型網站使用。甲骨文公司於1989年進入中國，在北京、上海、廣州和成都設有分支機構。
(8)資料庫回滾語句擴展閱讀：
資料庫技術的應用及特點
資料庫最初是用作大型公司或組織中大規模事務處理的基礎。後來，隨著個人電腦的普及，將資料庫技術移植到pc中，實現單用戶個人資料庫應用。然後由於PC機在工作組內聯網，資料庫技術被移植到工作組級。
資料庫現在在Internet和Intranet上廣泛使用。在20世紀60年代中期，資料庫技術被用來解決文件處理系統的問題。當時，資料庫處理技術仍然非常脆弱，經常出現應用程序無法提交的情況。
20世紀70年代，關系模型的誕生為資料庫專家提供了一種構建和處理資料庫的標准方法，促進了關系資料庫的發展和應用。
現在，資料庫技術與Internet技術一起被用來在組織內聯網、部門區域網、甚至WWW上發布資料庫數據。
⑼ 對於已經執行成功的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數據修改回滾
SQL：回滾事務日誌文件中的事務
問：怎樣使用Transact-SQL回滾某個位於事務日誌文件中的事務（例如，ID 0000:0010a183）？
答：出於預防數據錯誤的考慮，SQL Server並不支持個別事務的回滾。舉例來說，假設兩個事務T1和T2使用現金余額域。T1添加了500美金，T2使用更新後的值進行了某個操作。如果回滾T1，則T2可能是錯誤的。但是，您可以使用時間戳或事務日誌標記將日誌恢復至預定義的標記或時間點。以下兩個例子說明了如何使用SQL Server 2000語法。
例1：使用時間戳將日誌進行時點恢復
使用以前的完全備份恢復資料庫，並使其為日誌恢復做好准備。
RESTORE DATABASE pubs FROM DISK = N'C:\Backups\Fullbackup.bak' WITH NORECOVERY
現在您可以將日誌前滾到合適的時間點，並使資料庫可供使用。請注意，STOPAT在資料庫正在執行大容量日誌時禁止執行。
RESTORE LOG pubs FROM DISK=N'C:\Backups\Logbackup.bak' WITH RECOVERY,STOPAT='02/11/2002 17:35:00'
例2：使用資料庫標記將日誌恢復到預定義時間點的語句
在事務日誌中置入一個標記。請注意，被標記的事務至少須提交一個更新，以標記該日誌。
BEGIN TRAN MyMark WITH MARK
UPDATE pubs.dbo.LastLogMark SET MarkTime = GETDATE()
COMMIT TRAN MyMark
按照您常用的方法備份事務日誌。
BACKUP LOG pubs TO DISK='C:\Backups\Fullbackup.bak' WITH INIT
現在您可以將資料庫恢復至日誌標記點。首先恢復資料庫，並使其為接受日誌恢復做好准備。
RESTORE DATABASE pubs FROM DISK=N'C:\Backups\Fullbackup.bak' WITH NORECOVERY
現在將日誌恢復至包含該標記的時間點，並使其可供使用。請注意，STOPAT在資料庫正在執行大容量日誌時禁止執行。
RESTORE LOG pubs FROM DISK=N'C:\Backups\Logbackup.bak' WITH RECOVERY,
STOPAT='02/11/2002 17:35:00'
—Microsoft SQL Server 開發團隊