Article Directory
CURD plus control
The scenario of simulating a ticket buying system is as follows:
MySQL is destined to be accessed by multiple clients. This is for sure. All the data is stored. The data may be used by one thread in the upper layer, and another thread wants to get it from the database, and other clients also want to access it. To obtain data, the data is shared by everyone, so the mysqld service will have multiple requests to allow us to perform CURD operations on the data. MySQL internally uses multi-threaded methods to implement data storage related operations, so there will be concurrency of data access scene. Therefore, relational databases provide transactions, and MySQL is generally more complete.
Actual scene:
In a ticket selling system, it includes ticket id, name, and quantity nums. When client A checks that there is still one ticket, he sells the ticket. Before updating the database, client B checks the number of tickets and finds that it is greater than 0, so the ticket was sold again, and then A updated the number of tickets to the database. This is the same ticket sold twice , which is not in line with normal business logic.
CURD needs to meet the following attributes to solve the above problems:
the process of buying tickets must be atomic, buying tickets should not affect each other, tickets should be permanently valid after buying, and a definite state must be established before and after buying
what is a thing
A transaction is composed of a group of DML statements. These statements are logically related. This group of DML statements either all succeed or all fail, which is a whole . MySQL provides a mechanism to ensure that we achieve this effect. The transaction also stipulates that different clients see different data
A transaction is something to do or do, and it is mainly used to process data with a large amount of operations and high complexity . For example: when you graduate, your data is no longer needed in the background MySQL of the educational administration system, so when you want to delete your basic information (such as name, phone number, place of origin, etc.), you will also delete the information related to you Other information, such as: grades in various subjects, school performance, and even articles you have posted on forums, etc. In this way, multiple MySQL statements are required, and all these operations together form a transaction .
For a MuSQL database, there may be more than one transaction running. At the same time, there may even be a large number of requests packaged into transactions. When a transaction processing request is initiated to the MySQL server, each transaction has at least one SQL, and finally many SQLs. In this way, if everyone accesses the same table data without protection, problems will arise. It may even be because the transaction is composed of multiple SQLs, there will be errors in the execution half or do not want to execute, so the ones that have been executed should do this:
A complete transaction is definitely not a simple SQL collection, but must also satisfy the following four attributes:
原子性: Su Wo in a transaction operates again, either all of them are completed, or none of them are completed, and it will not end at a certain link in the middle. If an error occurs during the execution of the transaction, it will be rolled back (Rollback) to the state before the transaction started, as if the transaction had never been executed.
一致性: The integrity of the database is not compromised before and after the transaction begins. This means that the written data must fully comply with all preset rules, including data accuracy, seriality, and the subsequent database can spontaneously complete the scheduled work.
隔离性: The database allows multiple concurrent transactions to read, write and modify data at the same time. Isolation can prevent data inconsistency caused by cross-execution when multiple transactions are executed concurrently. Transaction isolation is divided into different levels, including read uncommitted (Read uncommitted), read committed, repeatable (repeatable read) and serializable (Serializable)
持久性: After the transaction processing is completed, the modification to the data is permanent, even if the system fails, it will not be lost.
The above four properties can be referred to as ACID for short .
Atomicity (or Indivisibility)
Consistency (
Isolation, also known as Independence)
Durability.
Why do things happen
Transactions are designed by the MySQL writers. The essence is that when applications access the database, transactions can simplify our programming model, and we don’t need to consider various potential errors and concurrency issues. When we use transactions, either Commit, or roll back, we will no longer consider network exceptions, server downtime, and change a piece of data at the same time.
So transactions are essentially for application layer services, not inherently accompanied by database systems.
We will later refer to a row of information in MySQL as a row of records.
transaction version support
In MySQL, only databases or tables that use the Innodb database engine support transactions, MyISAM does not support
Let's take a look: the view command is as follows
show engines \G
It can be clearly seen that MyISAM does not support transactions.
How the transaction is committed
There are two common ways to submit a transaction: 自动提交,手动提交
View transaction submission method:
show variables like 'autocommit';
Use SET to change MySQL's autocommit mode:
-- 关闭自动提交
set autocommit=0;
-- 打开自动提交
set autocommit=1;
mysql is a server process, essentially a network service, the underlying layer uses the tcp protocol, and the default port is 3306:
For the port number, you can change the port number of mysql. If you don’t need a particularly common port number, you can go to the /etc/my.cnf file to modify it.