Transaction processing of the database

A transaction is a mechanism that ensures that multiple SQL statements are treated as a single unit of work. Transactions have the following effects: Consistency: Simultaneous queries and updates do not conflict with each other, and other users do not see data that has changed but has not yet been committed. Recoverability: Once the system fails, the database automatically recovers the unfinished transaction completely.

A transaction is a unit of integrity, and the execution of a transaction transforms the database from one consistent state to another. Therefore, if the transaction is executed in isolation, but if multiple transactions are staggered, they may interfere with each other, resulting in inconsistent database status. In a multiuser environment, the database must avoid conflicting queries and updates at the same time. This is important if the data being processed can be changed by another user's modifications when the processing is running, and the processing result is ambiguous.

MySQL transaction support is not tied to the MySQL server itself, but is related to the storage engine: MyISAM: Does not support transactions, for read-only programs to raise High-performance InnoDB: Support Acid transactions, row-level locks, concurrency

A transaction is a continuous set of database operations, as if it were a single unit of work. In other words, it will never be a complete transaction unless each individual operation within that group is successful. If any operation in the transaction fails, the entire transaction fails.
　　
Transactions have abbreviated acid for four standard properties, commonly referred to as: atomicity: Ensure that all operations within the work unit are completed successfully, otherwise the transaction will be aborted at the point of failure, and the previous operation will be rolled back to the previous state. Consistency: A transaction that is successfully committed after the database has been correctly changed to state. Isolation: Enables transactions to operate independently and transparently from one another. Persistence: Ensures that the results or effects of a committed transaction still exist in the event of a system failure.

In MySQL, a transaction starts working and ending with a commit or ROLLBACK statement. A large number of transactions are formed between the SQL commands for the start and end statements.
Commit & ROLLBACK: These two keyword submissions and rollbacks are primarily used for MySQL transactions. When a successful transaction completes, the commit command should cause all participating table changes to take effect. In the event of a failure, you should issue one of the tables referenced in the transaction returned by the rollback command to the previous state.
The transaction behavior that can be controlled is called the autocommit set session variable. If Autocommit is set to 1 (the default), then each SQL statement (in transaction or not) is considered a complete transaction and is committed by default when it is completed. When Autocommit is set to 0 o'clock, the set autocommit = 0 command is issued, and the subsequent sequence of statements acts like a transaction until a definite commit statement is made, and no activity is committed.
MySQL Thing processing example:
　　　
1, with Begin,rollback,commit to achieve begin start a transaction ROLLBACK TRANSACTION rollback COMMIT TRANSACTION Confirmation

2, directly with set to change the automatic submission mode MySQL MySQL default is automatically submitted, that is, you submit a query, directly executed. You can implement transaction processing by using Set autocommit = 0 To prevent autocommit set autocommit = 1 to turn on autocommit.

But be aware that when you use set autocommit = 0, all of your later SQL will be transacted as transactions until you end with a commit or rollback, and notice that when you end the transaction, you start a new transaction. In the first method, only the current is done as a transaction!