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 也会执行。