1. What is a business
A transaction is a set of operations of the program. Either all are executed successfully, or after failure, all operations return to the state before execution.
Transaction generally refers to something to be done or done. In computer terms, it refers to a program execution unit (unit) that accesses and may update various data items in the database. Transactions are usually caused by the execution of user programs written in high-level database manipulation languages or programming languages (such as SQL, C++ or Java), and are defined by statements (or function calls) in the form of begin transaction and end transaction. A transaction consists of all operations performed between the beginning of the transaction and the end of the transaction.
2. Transaction characteristics (ACID)
- Atomicity (atomicity) A transaction is an indivisible unit of work, and the operations included in the transaction are either done or not done.
- Consistency (consistency) transaction must change the database from one consistent state to another consistent state. Consistency and atomicity are closely related.
- Isolation (isolation) The execution of a transaction cannot be interfered by other transactions. That is, the internal operations and data used by a transaction are isolated from other transactions executed at the same time, and each transaction executed concurrently cannot interfere with each other.
- Persistence (durability) Durability, also known as permanence, means that once a transaction is committed, the changes to the data in the database should be permanent. The following other operations or failures should not have any effect on it.
3. The isolation level of the transaction
3.1 Problems arising from the isolation theory
The isolation level of the transaction is because the transaction is isolated, so when multiple transactions concurrently operate on a piece of data, some problems are likely to occur, such as dirty reads, phantom reads, and non-repeatable reads.
3.1.1 Dirty Read
A transaction can read the data of another uncommitted transaction
Zhang San went out for dinner and found that there was no money in the payment software, and asked Li Si to transfer 100 yuan to him. When Li Si transferred the money to him, the transfer transaction only modified the amount of Zhang San in the database, and the transaction has not yet been submitted, but Zhang San has already read it. I got 100 yuan in my wallet and paid 15 yuan to the merchant, but after Li Si’s transfer transaction added 100 to Zhang San’s balance, there was a problem when he needed to subtract 100 yuan from his account, which caused the transfer transaction to roll back. Zhang San has already spent 100 yuan out of 15 yuan, there will be problems here
3.1.2 Non-repeatable read
The data read before and after a transaction is inconsistent, that is, the same data is read repeatedly in a transaction, but the data is inconsistent, which is called non-repeatable read.
When transaction A is read for the first time, it is found that the balance is 0 yuan, transaction B is executed concurrently, the balance is modified to 100 yuan, transaction B is submitted, and transaction A is queried again, and it is found to be 100 yuan, and the data in the two queries is inconsistent .
Zhang San’s bank card had 3,000 yuan, Zhang San’s wife took the bank card, and Zhang San paid 15 yuan with her mobile phone during dinner. When paying, Zhang San’s card had 3,000 yuan, but at the same time, Zhang San’s wife took the card. I transferred 3000 to my own payment software, and the bank found that the first query was 3000 yuan during Zhang San’s payment, but after subtracting the balance, I checked again and found that it was 0 yuan.
3.1.3 Phantom reading
The data entry seen by a transaction for the first time is inconsistent with the data entry seen for the second time, that is, repeated reading, and it is found that there are a few more or fewer data entries in the database, which is like an illusion, also called Phantom reading.
When transaction A reads for the first time, it is seen that there are 5 data in the database table, transaction B is executed concurrently, a new data is added, transaction B is submitted, and transaction A is found to be 6 data when it is queried again.
Note : The biggest difference between non-repeatable reading and phantom reading: non-repeatable reading is the change of data value, while phantom reading is the change of data entry.
3.2 Four isolation levels
| Isolation level | Dirty read | Non-repeatability | Phantom reading |
|---|---|---|---|
| Uncommitted read | ✔ | ✔ | ✔ |
| Submitted | ✖ | ✔ | ✔ |
| Repeatable | ✖ | ✖ | ✔ |
| Serialization | ✖ | ✖ | ✖ |
3.2.1 Uncommitted Read
Literally, it can be seen that uncommitted read means that transaction A has not yet been committed, and other transactions can read data that has been modified by A, and dirty reads will definitely occur.
Non-repeatable reads and phantom reads. Because it is in the execution of A transaction, after other transactions modify the data and commit the transaction, the A transaction will appear phantom and non-repeatable reads.
3.2.2 Submitted Read
The committed read is that the A transaction must be committed, and other transactions can read the modified data. Dirty reads are solved, but non-repeatable reads and phantom reads are not resolved.
3.2.3 Repeatable reading
Repeatable read means that after transaction A reads the data, other things modify the data and submit the transaction. Transaction A reads again, but the data read for the first time is consistent. It solves non-repeatable reads, but does not solve the illusion. read.
3.2.4 Serialization
Serialization is to execute transactions serially. Because a single transaction is executed, there is no concurrency, and there will be no dirty reads, phantom reads, and non-repeatable reads.
Note : mysql supports repeatable reading by default.
3.2.5 Problems caused by mysql default repeatable read
(1) Case 1
Transaction A modifies a certain piece of data in the database and is not committed. Transaction B is executed concurrently. When transaction B modifies, deletes, or adds to the database, transaction B waits because transaction A is not committed. After transaction A is committed, B The transaction continues to perform the modification, transaction B uses the data before modification of transaction A as the original value, resulting in an error
Li Si’s bank account has 100 yuan, and Zhang San transfers 100 yuan to Li Si. While the transaction is being executed, Wang Wu also transfers 100 yuan to Li Si, because Zhang San’s transfer transaction has not been submitted and Wang Wu’s transfer transaction is waiting (the transaction has been modified Operation, so you need to wait for Zhang San’s transaction to be submitted). After Zhang San’s transfer transaction was submitted, Wang Wu’s transaction was modified with the original 100 yuan, resulting in a problem with Li Si’s account now having 200 yuan.
solution
Lock the query of transaction B. After the lock is added, the query statement of transaction B will wait for transaction A to be submitted before querying, ensuring data security
4. SQL implementation transaction
4.1 Syntax
4.1.1 Open a transaction (choose one of the two)
begin;
start transaction;
4.1.2 Commit transaction
commit;
4.1.3 Rolling back a transaction
rollback;
4.2 Demo
4.2.1 Table structure
DROP TABLE IF EXISTS `test_account`;
CREATE TABLE `test_account` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`username` varchar(32) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NULL DEFAULT NULL,
`balance` double(11, 0) NULL DEFAULT NULL,
PRIMARY KEY (`id`) USING BTREE
) ENGINE = InnoDB AUTO_INCREMENT = 3 CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci ROW_FORMAT = Dynamic;
-- ----------------------------
-- Records of test_account
-- ----------------------------
INSERT INTO `test_account` VALUES (1, '张三', 1000);
INSERT INTO `test_account` VALUES (2, '李四', 1000);
SET FOREIGN_KEY_CHECKS = 1;
4.2.2 Cases of transfer transactions
Successful transfer
Zhang San transfers 500 yuan to Li Si, deducts 500 from Zhang San’s account and adds 500 to Li Si’s account.
start transaction;
update test_account set balance=balance-500 where username='张三';
update test_account set balance=balance+500 where username='李四';
commit;
Transfer failed
Zhang San transfers 500 yuan to Li Si, deducts 500 from Zhang San’s account and adds 500 to Li Si’s account.
start transaction;
update test_account set balance=balance-500 where username='张三';
update test_account set balance=balance+500 where username='李四';
rollback;
