一个事务，不管是commit还是rollback都表示这个事务的结束
一个表：
mysql> select * from bb;
+----+------+
| id | b |
+----+------+
| 1 | 1000 |
| 2 | 2000 |
+----+------+
假如我们开启了两个终端，一个终端先执行以下操作：
mysql> update bb set b=900 where id=1;
Query OK, 1 row affected (0.05 sec)
Rows matched: 1 Changed: 1 Warnings: 0
mysql> start transaction;
Query OK, 0 rows affected (0.00 sec)
mysql> update bb set b=b-900 where id=1;
Query OK, 1 row affected (0.02 sec)
Rows matched: 1 Changed: 1 Warnings: 0
然后在另一终端执行以下操作：
mysql> update bb set b=7000 where id=2;
Query OK, 0 rows affected (0.09 sec)
Rows matched: 1 Changed: 0 Warnings: 0
mysql> select * from bb;
+----+------+
| id | b |
+----+------+
| 1 | 1000 |
| 2 | 7000 |
+----+------+
2 rows in set (0.01 sec)
这时你还看不出什么，接下来就要注意了，还是在这个终端，执行：
mysql> update bb set b=5000 where id=1;
我们会看到当前终端被阻塞，原因是，id=1的这一行，正在被另一个终端的事务中执行，且这个事务还没有结束。那么就相当于这一行有一把锁，除非这个事务结束了，这个锁才能消失
于是，我们回到第一个终端，执行commit；
此时第二个终端才不被阻塞，当前的语句才被执行，最后查看id为1的行，b的值，发现是5000（注意先后顺序，不是4100）
当然，被阻塞的终端二也会有一个等待时间，如果超出了等待时间，则跳过阻塞（阻塞的语句也就没执行成功。就好比上面这个例子，如果我们等了很久才在第一个终端commit，那么最后查看id为1的行的b是100，因为1000-900=100,而update bb set b=5000 where id=1;又没有生效