mysql basics three: transaction

6 affairs

6.1 Talk about the ACID and isolation level of the transaction

1 Explain that the three features of AID are all for C (consistency) services. General databases need to use transactions to ensure the consistency of the database.
It's better to explain in detail when it is correct:
ACID is an acronym used to describe four key characteristics of database transactions, including:

  • Atomicity: A transaction must be regarded as an indivisible minimum unit of work. All operations of the entire transaction are either committed successfully or rolled back on failure. For a transaction, only one of them cannot be executed. part of the operation.
  • Consistency: Transactions should ensure that the database transitions from one consistent state to another. Consistency means that the database should meet predetermined constraints, such as data integrity constraints.
  • Isolation: Isolation is required between multiple concurrent transactions to prevent data corruption. Isolation ensures that during the execution of a transaction, its operation and the generated intermediate state are isolated from other concurrent transactions, that is, the execution of a transaction should not affect other transactions.
  • Durability: Once a transaction is committed, changes to data are permanent. Even if there is a system failure, the modified data will not be lost.
    These four characteristics are required for database transactions to ensure data consistency and reliability. The three characteristics of A, I, and D can be regarded as realizing C (consistency) services. Transactions are to ensure the integrity and consistency of operating databases, which is the importance of ACID.

2 Four isolation levels are defined in the SQL standard, namely: . . .

6.2 Assume that the first thread starts a transaction and reads it once at the beginning and at the end, but the second thread in the middle modifies the data in it. At this time, the data read by the first thread for the second time is thread two Modified or pre-modified data? (important)

Answer: The answer to this question depends on the isolation level of your database transactions.

If the transaction of thread 2 is not committed: when reading the uncommitted isolation level, the data can be read, but the data modified by thread 2 cannot be read at the level of read committed and RR, and only the modified data can be read previous data.

If the transaction of thread 2 is committed: there is no problem of reading uncommitted data at this time, but when reading the committed isolation level, the modified data can be read, but at the RR level, the pre-modified data is read data .

At the Serializable level, all transactions are executed serially. If the transaction of the first thread is executed first, only the data before modification can be read in the whole process. After it is executed, the second thread can continue to perform subsequent modification operations.

You can also take a look at the following summary:

  • Read Uncommitted: At this level, a transaction may see uncommitted data from other transactions. So in your example, the data read by thread one for the second time will be the modified data by thread two.
  • Read Committed: At this level, a transaction can only see data that has been committed by other transactions. In your example, if thread two has committed the transaction before thread one's second read, then thread one will read the modified data of thread two. If thread 2 has not submitted, then thread 1 will read the data before thread 2 modifies.
  • Repeatable Read (repeatable read): At this level, the data seen by a transaction is consistent throughout the process. That is, after a transaction starts, it will no longer see data modifications made by other transactions. In your example, the data read by thread one for the second time will be the data before thread two modifies, regardless of whether thread two has committed the transaction or not.
  • Serializable: This is the strictest isolation level and requires all transactions to be executed serially. This level prevents all concurrency problems.

It should be noted that the higher the isolation level, the better the data consistency, but the concurrency performance may be reduced. Therefore, in the actual system, it is necessary to select the appropriate isolation level according to the actual needs and performance requirements.

6.3 How to realize the snapshot of mvcc

Using the undo log log, the latest log is also a snapshot, which will be pointed to by a hidden pointer db_roll_ptr of the data row

6.4 write sql

There is a teacher table with fields id and name, and a t_s table representing teacher-student with fields tid and sid. Now let you query the teachers whose number of students is greater than 10.

select t.name from teacher t left join t_s ts on t.id=ts.id group by t.id having count(ts.sid)>10

6.5 Is the isolation level of the database all for read operations?

The isolation level of the database is not only for read operations, but also for write operations. But often we pay more attention to the consistency of read operations, because in a concurrent environment, different isolation levels will have different impacts on read operations, such as dirty reads, non-repeatable reads, and phantom reads. Write operations are usually guaranteed by the database's concurrency control mechanism (such as locks).

6.6 The transaction itself cannot guarantee the protection of writing, it needs to be completed together with the lock

you are right. Transactions just provide a mechanism to ensure that a logical unit of work consisting of a set of database operations is either fully completed or not completed at all (this is the atomicity of a transaction). But the transaction itself cannot prevent multiple transactions from modifying the same data concurrently, which may lead to data inconsistency.

In order to solve this problem, database systems usually use concurrency control mechanisms such as locks to prevent conflicts between concurrent transactions. When a transaction tries to modify a piece of data, the database system will lock the data to prevent other transactions from modifying the data at the same time. Until this transaction completes (commits or rolls back) and releases the lock, other transactions cannot modify this data.

This is why we say that the isolation level of the database provides protection against write operations. In fact, this protection is implemented by the concurrency control mechanism of the database (such as locks). Different isolation levels use different concurrency control strategies, thus providing different degrees of write operation protection.

6.6.1 If a transaction is in the case of repeatable reading, after the first read operation, the update statement is used to update the operation. At this time, will the readview be regenerated and then updated based on the latest data?

Under the isolation level of repeatable reading, if the update statement is used to update the operation after a read operation, the readview will not be regenerated. Under the repeatable read isolation level, a transaction generates a snapshot at the beginning, and subsequent operations are performed on the basis of this snapshot. When the transaction executes the update statement, the update operation will be performed according to the previous snapshot. Even if other transactions modify this data, the data seen by this transaction is still the data when the snapshot was generated at the beginning.

6.6.2 What is the consistency scope of mysql database transactions?

Recommendation: How to understand the concept of consistency in database transactions?
In this article, it is pointed out that the consistency of transactions is constrained by the integrity of the database and the integrity of the business characteristics of the application layer, and the concurrency constraints are also required by the business constraints of the application layer, so the granularity of the consistency of mysql transactions can be single The consistency of threads can also be the consistency of concurrency under multi-threading, which depends on business needs. Of course, general concurrent business needs to ensure this kind of concurrency consistency, so locks are used to solve problems such as overselling and phantom reading. , but single-threaded business does not need to use locks.

6.6.3 At the RR level, use the select statement twice to query the number of record hops in the relevant interval, and another transaction in the middle inserts a statement into this interval. Will you find one more data in this interval when you select this interval for the second time?

At the RR (Repeatable Read) level, using the SELECT statement twice to query the same recordset should return the same result, even if there are other transactions inserting records into this interval between the two queries. Because under the RR isolation level, a transaction will create a data snapshot (read view) at the beginning, and subsequent read operations are based on this snapshot, and will not see the modifications made by other transactions after the transaction starts. Therefore, if other transactions insert new records after the transaction started, the current transaction will not see these new records in subsequent queries.

It should be noted that although the RR level can ensure that existing records remain consistent during a transaction, it does not prevent other transactions from inserting new records. These new records inserted during the transaction become visible when the current transaction commits.

This is why the RR isolation level cannot completely avoid phantom reads. Phantom reading refers to the sudden appearance or disappearance of the result set of a query after a certain transaction is committed . At the RR level, transactions do not see new rows inserted by other transactions, but when the transaction commits, these new rows become visible, which may lead to phantom reads.

7 Serialization related issues

7.1 Serialization must ensure that the read data is the latest, right?

Yes, serialization is the highest level in the database isolation level. It can ensure that transactions are executed serially, thereby avoiding various problems caused by concurrently executed transactions, including the problem that the read data is not up-to-date. At the serialization level, the execution results of transactions are the same as the results of their serial execution.

7.2 Is the serialized transaction all the things in the database or the associated transaction of a certain table? What is the granularity of serialization?

The granularity of serialization depends on the specific database management system and its concurrency control mechanism. In some database systems, serialization may lock the entire database, so that all transactions must be executed serially. In some other database systems, serialization may only lock the data accessed by the transaction, so that transactions accessing different data can be executed in parallel.

What is the granularity of serialization in mysql?

The serialization (SERIALIZABLE) isolation level in MySQL will lock all read operations to prevent other transactions from modifying data concurrently, thereby achieving serial execution of transactions. This means that only one transaction can operate on the same data at a time. So it can be said that MySQL's serialization isolation level is performed at the data row level, and the specific granularity depends on the data range of the transaction operation.

7.3 Can the serialization mechanism also be implemented on the client side, such as the scenario of message queue single-threaded consumption

Yes, the serialization mechanism is not limited to databases, it can be applied to any scenario that requires concurrency control. For example, in the message queue, you can let each consumer thread process a part of the message, so that the messages processed by different consumer threads will not overlap, so that an effect similar to serialization can be achieved. However, it should be noted that this method depends on the message distribution strategy. If the message cannot be evenly distributed to each consumer thread, the consumer thread may appear idle, resulting in a decrease in system throughput.

8 What are the characteristics of database things, and what are they guaranteed and implemented? (Byte backend side)

8.1 Database transactions have the following four key properties, often referred to as ACID properties:

  1. Atomicity : Atomicity ensures that a transaction is an indivisible unit of operation, either all executed or not executed at all. If any part of a transaction fails, the entire transaction will be rolled back to the original state to ensure data consistency. Atomicity is usually implemented by a database management system (DBMS), using transaction logs and rollback mechanisms to ensure it.

  2. Consistency : Consistency ensures that transactions transform the database from one consistent state to another. This means that the database must satisfy certain integrity constraints and rules before and after transaction execution to ensure data integrity. Consistency is usually guaranteed by application and database constraints.

  3. Isolation : Isolation ensures that when multiple transactions are running at the same time, each transaction feels as if it is the only one running and will not be affected by other transactions. Isolation is achieved by using locking mechanisms, multiversion control, or other concurrency control techniques to prevent data races and inconsistent reads.

  4. Durability : Durability ensures that once a transaction is successfully committed, its results will be permanently stored in the database and will not be lost even if the system crashes or is powered off. Persistence is typically achieved by writing the transaction log to non-volatile storage such as a hard disk.

8.2 Realization of the four major features

Together, these ACID properties ensure transactional reliability and data integrity. Internally, a database management system implements these features using logging and recovery mechanisms. How this is done can vary, but generally involves the following steps:

  • Transaction Log (Transaction Log) : The database records all changes (insert, update, delete) of a transaction into the transaction log for recovery when needed. This includes logging all changes before committing the transaction to ensure atomicity and durability.

  • Concurrency Control : To achieve isolation, database management systems use techniques such as locking, timestamping, or multi-version control to manage concurrently running transactions. This ensures that each transaction does not interfere with the operations of other transactions.

  • Rollback (Rollback) : If any part of the transaction fails or an error occurs, the database system will use the information in the transaction log to roll back the transaction to the previous state to ensure atomicity.

  • Durability Guarantee : The database management system ensures that changes in the transaction log are written to persistent storage, such as a hard disk. This ensures that even if the system crashes or loses power, the results of the transaction are not lost.

In short, ACID characteristics are the key characteristics of database transactions, which are realized and guaranteed by the internal mechanism and recovery strategy of the database management system. These characteristics ensure the reliability and integrity of data, so that the database can still maintain consistency in the face of various failures and concurrent access.

8.3 What are the ACID guarantees of undo log, redo log and bin log for transactions?

8.4 Database isolation level:

Database isolation levels define visibility and interoperability between different transactions. The SQL standard defines four isolation levels, from lowest to highest are Read Uncommitted, Read Committed, Repeatable Read, and Serializable.

  1. Read Uncommitted : Allows a transaction to read uncommitted modifications of another transaction, which is the lowest isolation level and is generally not recommended because it may lead to dirty reads and non-repeatable reads.

  2. Read Committed : Guarantee that one transaction will not read the modifications of another uncommitted transaction. This is the default isolation level for most database systems.

  3. Repeatable Read : Ensures that the data seen by a transaction remains consistent during execution, even if other transactions insert or modify it in the meantime. This is the default isolation level for MySQL.

  4. Serializable : Provides the highest isolation level, ensuring that there are no concurrency issues between transactions, but performance is usually lower.

8.5 The difference between the MVCC mechanism of RC and RR isolation levels:

  1. RC (Read Committed) isolation level : Under the RC isolation level, transactions can read the data of committed transactions, but cannot read the data of uncommitted transactions. MVCC does this internally by creating a snapshot of each transaction to ensure that one transaction does not read another transaction's uncommitted changes.

  2. RR (Repeatable Read) isolation level : Under the RR isolation level, transactions can read the data of committed transactions, and will not see the results of other transactions' insert, update, or delete operations during the entire transaction. MVCC also comes into play here, but it creates a snapshot at the start of a transaction and keeps it there throughout the transaction to ensure data consistency.

8.6 Avoid phantom reading under RR isolation level (MVCC + Next-Key Locking):

Phantom reading refers to the situation where the same query is executed in one transaction, but the result set is inconsistent because other transactions insert or delete rows that meet the query conditions. Under the RR isolation level, in order to avoid phantom reading, the database uses MVCC and Next-Key Locking mechanism to handle.

  • MVCC : MVCC ensures that queries are not affected by other transactions by creating a snapshot of the transaction. Under the RR isolation level, the query will use the snapshot at the beginning of the transaction, which means that the insertion, update and deletion of other transactions during the query will not affect the query results.

  • Next-Key Locking : Next-Key Locking is a lock mechanism, which is used to avoid phantom reading under the RR isolation level. When a transaction executes a SELECT statement, Next-Key Locking will lock all records within the query range, and will also lock the "gap" of records that may be inserted after the query to prevent phantom reading. This ensures that other transactions cannot insert new records that satisfy the query conditions during the query.

To sum up, under the RR isolation level, through the MVCC and Next-Key Locking mechanism, the database ensures the consistency of the query and avoids the problem of phantom reading. MVCC provides a snapshot to maintain the consistency of the query, while Next-Key Locking ensures that the data during the query will not be disturbed by the insert operations of other transactions. The combination of these two mechanisms provides a guarantee for data consistency under the RR isolation level.

8.7 Only using Next-Key Locking can guarantee to avoid phantom reading. Doesn’t Next-key lock gaps and rows? It is a combination of row locks and gap locks, so other transactions should not be allowed to modify, and then just Can phantom reading be guaranteed? But can you guarantee repeatable reading?

8.8

Guess you like

Origin blog.csdn.net/yxg520s/article/details/132517178