数据库的隐式提交
先看一段SQL,最后一条SQL的输出你认为是什么?
1
2
3
4
5
6
7
|
SET
AUTOCOMMIT = 1;
BEGIN
;
INSERT
INTO
t1
VALUES
(1);
CREATE
TABLE
t2 (pk
int
primary
key
);
INSERT
INTO
t2
VALUES
(2);
ROLLBACK
;
SHOW TABLES;
|
答案是:t1, t2都存在!
1
2
3
4
5
6
7
8
|
mysql> show tables;
+
----------------+
| Tables_in_test |
+
----------------+
| t1 |
| t2 |
+
----------------+
2
rows
in
set
(0.00 sec)
|
更奇怪的是:t1中的1也插入成功了!
1
2
3
4
5
6
7
|
mysql>
select
*
from
t1;
+
----+
| pk |
+
----+
| 1 |
+
----+
1 row
in
set
(0.00 sec)
|
为什么ROLLBACK没有生效呢?答案是:Implict Commit
执行CREATE TABLE语句前,之前的事务被隐式提交。因为AUTOCOMMIT=1,所以提交后也不会自动新创建任何事务,INSERT语句执行后立即提交,ROLLBACK不会作用在任何事务上,所以得到了我们最后看到的结果。
稍微改一下,让AUTOCOMMIT=0,会怎样呢?
1
2
3
4
5
6
7
|
SET
AUTOCOMMIT = 0;
BEGIN
;
INSERT
INTO
t1
VALUES
(1);
CREATE
TABLE
t2 (pk
int
primary
key
);
INSERT
INTO
t2
VALUES
(2);
ROLLBACK
;
SHOW TABLES;
|
答案是:t1, t2都存在!插入到t1中的1被提交(插入成功)但插入到t2中得2被回滚(没有插入成功)。之所以t1中的1被提交,是因为CREATE TABLE导致ImplictCOMMIT(注意,是COMMIT,不是ROLLBACK哦!),执行INSERT的时候,会自动开启一个新事务(AUTOCOMMIT=0的语义要求的行为)。所以t2中的2被ROLLBACK回滚。
为什么部分操作会导致Implict Commit?为什么这样设计?
为了保证直观上的原子性。假设不做Implict Commit,看看上面的语句会怎样:用户的心理预期是回滚t1的INSERT操作,以及t2的CREATE操作,INSERT操作。如果我们有能力做到这样,那的确是很完美的。但实际上我们很难做到,特别是在分布式系统中更难!因为CREATE TABLE操作背后涉及到了大量的操作,不仅仅包括对核心表的操作,还包括大量内存数据结构的更新(如Schema),以及存储系统的变更(如创建相应的数据块),工程上很难把这些操作做成原子的。
那么,应该如何做呢?比较折中的方式就是跟用户做一个约定:CREATE TABLE操作总默认COMMIT它之前的事务,这就是implict commit。
从MySQL文档看,他们做这一块的时候遇到了很多问题,至少在这里踩过两个坑。并且,随着版本的进化,他们还不断的让更多语句能引发implict commit。(转)