table of Contents
Brief introduction
Explanation
Transaction Control Language Transaction Control Language
Affairs
A transaction performed by a separate unit or group of units consisting of sql statement, or all the execution unit performs or does not perform all.
expand
Mysql in storage engine
- Data in mysql using various techniques stored in a file (memory) in
- By show engines; command to view Mysql storage engine support
In Mysql storage engine used in the most: innodb, MyISAM, memory and so on. Which innodb support services, and myisam, memory and so on does not support transactions
The difference between delete and truncate the transaction using
- delete transaction rollback support
truncate does not support transaction rollback
ACID transactions () property
### atomicity (Atomicity)
Atomicity means that a transaction is an indivisible unit of work operations in a transaction either occur or do not occurConsistency (Consistency)
Transaction must transform the database from one consistent state to another consistent state
Isolation (Isolation)
Isolation means the transaction is a transaction can not be performed by other transactions interference, i.e., operation and use of the data inside a transaction other concurrent transactions are isolated and can not interfere with each other between the respective transaction executed concurrently.
Persistent (Durability)
Persistence means that once a transaction is committed, it changed data in the database is permanent, then the other operations and database failures should not have any impact on its
Case
Transfer:
Ma: 1000 yuan
Ma: 1000 yuan
Ma Ma to the transfer 500, the following simple sql:
Update the table set Balance = 500 where name = 'Ma';
Update table set balance = 1500 where name = 'Ma';
If the above two sql, then the balance of the case 500 Ma reduced under linked database, if the transaction is not controlled, money becomes 500 Ma, Ma or 1000.
Creating a transaction
Implicit transaction
Introduction
The transaction is not obvious on and off.
Such as: insert, update, delete
Watch variables, execute the command:
show variables like 'autocommit';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| autocommit | ON |
+---------------+-------+To view, auto-commit is on, this is the case, do add, delete, change when the statement, the transaction is enabled by default, if the operation is a set of sql (multiple sql), invisible transactions useless.
Explicit Transactions
Introduction
Transaction has obvious opening and ending tags, use an explicit transaction, then the premise of the need to turn off autocommit
Close autocommit
mysql> set autocommit = 0;
Query OK, 0 rows affected (0.00 sec)
mysql> show variables like 'autocommit';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| autocommit | OFF |
+---------------+-------+grammar
Step 1: Turn Affairs
set autocommit = 0;
start transaction; # optional
Step 2: Write sql statement affairs
Statement 1;
Statement 2;
.............
Step 3: End Transaction
commit; commit the transaction
rollback; Rollback Transaction
Show
Commit the transaction:
set autocommit = 0;
start transaction;
update user_info set `password` = 'qqqqqqq' where id = 1;
update user_info set `password` = 'wwwwwww' where id = 2;
commit;
Query OK, 0 rows affected (0.00 sec)
Query OK, 0 rows affected (0.00 sec)
Query OK, 0 rows affected (0.00 sec)
Rows matched: 1 Changed: 0 Warnings: 0
Query OK, 0 rows affected (0.00 sec)
Rows matched: 1 Changed: 0 Warnings: 0
Query OK, 0 rows affected (0.00 sec)
mysql> select * from user_info where id in (1,2);
+----+-----------+----------+--------+---------------------+---------------------+
| id | user_name | password | status | create_time | update_time |
+----+-----------+----------+--------+---------------------+---------------------+
| 1 | liuyang | qqqqqqq | 1 | 2019-09-07 14:38:47 | 2019-09-07 14:38:47 |
| 2 | zhangsan | wwwwwww | 1 | 2019-09-07 14:38:47 | 2019-09-07 14:38:47 |
+----+-----------+----------+--------+---------------------+---------------------+
2 rows in set (0.06 sec)Roll back the transaction:
set autocommit = 0;
start transaction;
update user_info set `password` = 'xxxxxxx' where id = 1;
update user_info set `password` = 'aaaaaaa' where id = 2;
rollback;
Query OK, 0 rows affected (0.00 sec)
Query OK, 0 rows affected (0.00 sec)
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0
Query OK, 0 rows affected (0.00 sec)
mysql> select * from user_info where id in (1,2);
+----+-----------+----------+--------+---------------------+---------------------+
| id | user_name | password | status | create_time | update_time |
+----+-----------+----------+--------+---------------------+---------------------+
| 1 | liuyang | qqqqqqq | 1 | 2019-09-07 14:38:47 | 2019-09-07 14:38:47 |
| 2 | zhangsan | wwwwwww | 1 | 2019-09-07 14:38:47 | 2019-09-07 14:38:47 |
+----+-----------+----------+--------+---------------------+---------------------+
2 rows in set (0.08 sec)As seen above, if the transaction open, modify command is successful, the result will be stored in memory, and only after a commit will be written to disk persistence.
Running multiple transactions
To run multiple transactional, when the same data in these transactions to access the database, if not taken the necessary isolation mechanism, it can lead to all kinds of concurrency problems:
Dirty read: For two transactions T1, T2, T1 reads the field has been updated T2 but has not yet been submitted after the rollback if T2, T1 reads the content is temporary and ineffective.
Non-repeatable read: for two transactions T1, T2, T1 read a field, and the field after the update T2, Tl again read the same field, the value will be different
Magic Reading: for two transactions T1, T2, T1 is read from a field in a table, and then insert a new T2 rows in the table then, if the same table T1 is read again, a few will be more Row
Isolation of database transaction: database system must have the ability to isolate individual transactions run concurrently, so they do not affect each other, avoid all kinds of concurrency issues.
The extent of a transaction is isolated from other transactions is called the isolation level: the database transaction isolation level provides a variety of different isolation levels correspond to different degrees of interference, the higher the isolation level, data consistency is better, but the weaker concurrency
Four kinds of transaction isolation level
| Isolation Levels | description |
|---|---|
| READ UNCOMMITTED (read uncommitted data) | Allows transactions to read not change other matters submitted by the problem of dirty reads, non-repeatable read and phantom read will appear |
| READ COMMITED (read submitted data) | Only allows transactions to read changes have been submitted by other transactions, to avoid dirty reads, but non-repeatable read and phantom read problems may still arise |
| REPEATABLE READ (repeatable read) | Ensure that the transaction can be read many times the same value from a field, the duration of the transaction, other transactions prohibited on this field to be updated, to avoid dirty reads and non-repeatable read, phantom read but problems remain |
| SERIALIZABLE (serialization) | Ensure that the transaction can read the same rows from a table, the duration of the transaction, other prohibited transaction execution the table insert, update, and delete operations, more than a concurrency problems can be avoided, but the performance is very low. |
Oracle supports transaction isolation level 2: READ COMMITED and SERIALIZABLE. Oracle default transaction isolation level: READ COMMITED
Mysql supports four transaction isolation level, Mysql default transaction isolation level: REPEATABLE READ
Transaction isolation level demo
Dirty read
Figure 1
Figure 2
图3：图1 进行了 rollback
图4：再次查询图2
不可重复读
图1
设置数据库事务级别为 read-committed（读已提交数据）
修改数据，让这个事务处于未提交状态
图2
开启一个新事务
图3
图4：再次查询图2
发现数据已经更改，由此说明，read-committed事务中，如果T1事务未提交时查询T2事务中的数据时，避免了脏读，但是如果在T1事务已提交，T2事务再次查询时候，发现上一次查询结果数据已经改变（不可重复读）。由此可见，read-committed事务中也有可能出现脏读情况，只是相比 read-uncommitted事务会好些。
可重复读
图1
图2
由此可见，这个事务级别没有脏读
图3
图4
由此可见，repeatable read事务级别可解决脏读和不可重复读
幻读
图1
图2
图3
解决办法：事务隔离级别修改为最高级（serializabel）,修改为最高级别的话，T1开启事务修改数据，T2如果此时插入数据的话，会阻塞（加了锁，等待状态，如果等待时间长，就会超时），等到T1提交了事务，T2会继续执行。
事务级别总结
| 事务级别 | 脏读 | 幻读 | 不可重复读 |
|---|---|---|---|
| read uncommitted | √ | √ | √ |
| read committed | × | √ | √ |
| repeatable read | × | √ | × |
| serializabel | × | × | × |
命令
# 查看隔离级别
select @@tx_isolation;
# 设置隔离级别【session：当前，global：全局】
set session | global transaction isolation level 隔离级别;
Mysql和Oracle默认事务
Mysql中默认的是 repeatable read；
Oracle中默认的是 read committed
回滚点
savepoint node, which is the point of saving