table of Contents
Chapter One Database Basics
Article Directory
Preface
I think I didn't study deeply enough in university, and found that I need to use it in many places in actual work. So write down this article to help you sort out your knowledge, and hope that you can provide help if you need it. The road of self-study, if there are mistakes, please correct them, thank you very much !
The text from the author's inner understanding (and comprehensive consideration in combination with relevant literature):
Database transaction
1. Definition
A database transaction is an indivisible unit of work , consisting of all database operations performed between the beginning of the transaction and the end of the transaction. These operations are either all executed or not executed.
2. Requirements
A database transaction can include multiple database actions such as queries, modifications, deletions, and insertions. They are either completely confirmed as a whole or completely failed; a transaction can only include data operations on one database instance, which is required across multiple database instances Support for distributed transactions.
3. Impact
Database transactions will have a certain impact on the concurrent operation of the database and reduce the concurrency of the system.
Four, characteristics (ACID)
(1) A: Atomicity
All operations in an atomic transaction either all succeed or all fail. That is to say, each task in the entire transaction must be executed correctly. If any task fails to execute, the entire transaction will be terminated, and any previous modifications to the data will be undone (rolled back); if each task is executed If the execution is successful, the transaction will be committed. It is one of the important characteristics that distinguish the database system from all other file systems (file system errors cannot be recovered).
Let’s look at a small example~
If we need to perform transfer services, every step in the following table must be correct, otherwise we need to roll back to the initial state
| First | Check whether the current deposit balance is higher than the transfer amount |
|---|---|
| Second | Current deposit balance minus transfer amount |
| Third | Transfer account balance plus transfer amount |
(2) C: Consistency
The database always transitions from one consistent state to another consistent state.
Continuing the last small example ~
the deduction amount of the transfer-out account in our transfer service must be the same as the transfer-in amount of the transfer-in account.
| Q： | Who will guarantee? |
|---|---|
| A： | Transaction System & Application Developer |
| Q： | How to guarantee? |
| A： | Transaction system: to ensure the atomicity, isolation and durability of transactions. Application developers: to ensure that the database has appropriate constraints, and the business logic implemented in the transaction must be completely consistent with the expected real business conditions |
(3) I: Isolation
For concurrent transactions, the transaction must be executed independently without interfering with other processes or transactions. (There are level settings) That is to isolate the impact of multiple transactions running concurrently.
The two keys written in the front: shared locks and exclusive locks are two lock modes that achieve isolation levels, both of which are pessimistic locks.
Shared lock [ S lock_shared lock]:
is a read lock.
When transaction A adds S lock to data object B, transaction A can read B but cannot modify B. Other transactions can also add S lock to B, but cannot add X lock until A releases the S lock on B.
This ensures that other transactions can be readable but not writable by B before A releases the S lock on B.
Exclusive lock [ the X-Lock _exclusive lock]:
a write lock.
When transaction A adds X lock to critical section B, transaction A can read and write B, but other transactions cannot add any locks (shared lock, exclusive lock) to B until A releases the X lock on B.
This ensures that other transactions cannot read or write to B before A releases the X lock on B.
Summary:
Shared locks ensure that everyone can do read-only operations (eg select) together, and no one can write again;
exclusive locks ensure that only one person can process data (for data modification, eg insert, update, delete), and others Cannot read or write.
X locks have a higher priority than S locks. An X lock request may be inserted into the front of the S lock queue, but the S lock cannot be inserted in front of the X lock.
Note (can be skipped): The main means to achieve concurrency control can be roughly divided into optimistic concurrency control and pessimistic concurrency control.
① Pessimistic lock:
When operating data, it is believed that this operation will cause data conflicts, so each operation needs to obtain a lock to proceed.
The method is implemented by the database itself. When using it, you can directly call the database-related statement.
Scenarios are suitable for scenarios where the frequency of conflicts is high and the cost of retry is high, which provides a guarantee for the safety of data processing.
Disadvantages It reduces parallelism, takes more time, and increases the chance of deadlock.
Optimistic lock:
When operating data, do not think that this operation will cause data conflict (no lock), and then judge whether there is a conflict after the operation is over.
The method needs to be implemented by ourselves, and mechanisms such as version numbers can be used. The database does not come with it.
Scenarios are suitable for scenarios with many read operations and high response efficiency, which can improve program throughput.
Disadvantages If the lock granularity is not well grasped, the probability of update failure will be higher.
Transaction isolation level and solution
| Transaction isolation level | Dirty read | Not repeatable ③ | Phantom reading |
|---|---|---|---|
| Uncommitted read [Read Uncommitted] | allow | allow | allow |
| Submitted to read [Read Committed] | Prohibit | allow | allow |
| Repeatable Read [Repeatable Read] | Prohibit | Prohibit | allow |
| Serializable [Serializable] | Prohibit | Prohibit | Prohibit |
In the above table, under the same operating environment, the order of the different isolation levels is sorted according to concurrency from high to low, and isolation from low to high .
Notes (maybe after reading the notes, it’s still in the cloud, that's OK, we have a small example later):
②Dirty read: Transaction A reads data that has not been submitted by Transaction B
③Unrepeatable read: In transaction A, Read the same data twice, get different content
④Phantom reading: In transaction A, the same operation is read twice, the number of records obtained is different
The following examples help us better understand the isolation level of transactions:
1. Uncommitted read
Locking mechanism : add a row-level shared lock when writing a transaction, and no lock when reading a transaction.
Example: Transaction A modifies the content of a record but did not commit (commit). When the isolation level is uncommitted read , Transaction B can read the record content that was not submitted after A was modified. (Because it is a shared lock, other transactions can still read before the write transaction is committed)
What is the impact ? Once A performs a rollback operation (it can be rolled back without commit), the record content read by B before is dirty data , which causes dirty reads . [Not only dirty reading is unavoidable, but also non-repeatable reading (introduced in 2. Submitted reading below) and phantom reading (introduced in 3. Repeatable reading below).]
2. Submitted for reading
It is how to avoid dirty reads it? Locking mechanism : add a row-level exclusive lock when writing a transaction, and then release it at the end of the transaction; add a row-level shared lock when reading a transaction, and release the lock immediately after reading (do not wait until the entire transaction is over). (Ensure that other transactions cannot read or write this row when writing a row, and only after commit can read and write. When reading a row, other transactions can only read and cannot write this row)
Example: Transaction A does not end transaction A after querying a record . When the isolation level is committed to read , then transaction B modifies the record that A just queried (since it is committed to read, then B needs to commit after modifying the content).
What is the impact ? When A queried this record again, it was found to be different from the previously queried record (because B modified the content when transaction A did not end, causing transaction A to read inconsistently twice). The inconsistent records of before and after query result in non-repeatable reading . [Not only non-repeatable reading is unavoidable, but also phantom reading (introduced in 3. Repeatable reading below).]
3. Repeatable reading
It is how to avoid non-repeatable read it? Locking mechanism : add a row-level exclusive lock when writing a transaction, and add a row-level shared lock when reading a transaction, and they will be released until the end of the transaction . (Ensure that writing in the entire transaction is writing, reading is reading, and writing can only be done after the entire transaction is read.)
Example: Transaction A queries a set of records based on conditions, and then Transaction B inserts a record in the record range of A query conditions.
What is the impact ? When A uses the same method to retrieve the table again, a new record is found. This new record appeared to A suddenly, which caused a phantom reading . (Read and write transactions only add row-level locks. Although other transactions cannot modify these rows, they can add new rows, so phantom reads appear)
4. Serializable
It is how to avoid phantom read it? Locking mechanism : add table-level shared locks when reading transactions, and add table-level exclusive locks when writing transactions. (Avoid operations on the table by other transactions)
to sum up
| Transaction isolation level | to sum up | Database default isolation level |
|---|---|---|
| Uncommitted read [Read Uncommitted] | The modification in transaction A can be seen by other transactions even if it is not committed | |
| Submitted to read [Read Committed] | The modification in transaction A can only be seen by other transactions after it is committed. Non-repeatable reads and phantom reads may occur |
SQLServer , Oracle |
| Repeatable Read [Repeatable Read] | The results of each record seen in transaction A are consistent, and phantom reads may occur |
MySQL |
| Serializable [Serializable] | Strictly require data consistency to be achieved by a large number of locks, resulting in a large number of lock timeout and lock requisition problems, and low efficiency |
(4) D: Permanent Durability
Once the transaction is successfully submitted, its data modifications will be permanently saved in the database. At this time, even if the system crashes, the modified data will not be lost (disk damage does not include, and backups are required).