sql basics - transaction

sql basics

Transaction: In order to maintain the consistency and recovery of logical data, that is, within a logical operation, all operation units either do or do not do all.

Lock: When multiple users access the same database resource at the same time, a mechanism for managing and arranging the order of access is a technology that implements transactions and ensures the safe reading and writing of the database.

Deadlock: In the above lock mechanism, transactions suspend waiting due to different transactions preempting the same resources at the same time, resulting in huge load and resource waste caused by the database during deadlock.

 

Like other basic sql tutorials explaining sql transactions, in the process of withdrawing 100 from the bank, if it is successful, the account will be reduced by 100; if the machine fails in the middle, it will not be deducted. A transaction is: either execute all, or return to the original state at all.

 

1. Features:

Atomicity: All operations within a thing are indivisible as a whole, either all of them are performed or none of them are performed.

Consistency: After the transaction ends, all data states are correct.

Isolation type isolation: Different transactions do not interfere with each other, and deal with the data state before or after any other transaction is processed.

Persistence: After the transaction is committed, the data is permanent and cannot be rolled back.

 

2. Commit rollback:

In different environments, different databases may need to submit the displayed commit and rollback after the SQL statement is executed.

 

3. Lock:

We imagine that when multiple users use transactions to access the same resources at the same time, the following problems will be caused:

 1) Lost update: When multiple users update a data resource at the same time, it will inevitably cause coverage, and the last free result may cause abnormal data read and write

 2) Non-repeatable read: User A reads the same data multiple times before and after in a transaction, but at this moment user B updates the data, resulting in inconsistent data read by user A before and after;

 3) Dirty read: The first transaction is reading the data being processed by the second transaction. If the second transaction does not complete all the updates, half of the data that the first transaction continues to query on this result set will be updated Generally, it has not been updated, so the result is logically wrong.

 4) Phantom reading: User A reads the same data multiple times before and after a transaction, but at this moment, user B adds or deletes the database, causing user A to lose or increase the data read before and after;

 

 5) The lock is a database transaction processing mechanism generated to solve the above 4 issues. It wraps the collection of all a series of operations protected by a transaction, and other transactions cannot intervene, that is, locks (locks).

  <1>. Shared lock (s table level): It is called a read-only lock, which can read data concurrently, but cannot modify the data. That is, when there is a shared lock on a data resource, all transactions cannot update this resource, but can only read. Until the data read is complete, the shared lock is released.

  <2>. Exclusive lock (x row level): called exclusive lock, write lock. If a data resource is added, deleted, modified and searched, no other transaction is allowed to perform any operations until the lock is released.

  <3>. Update lock (U): mode to prevent deadlock. Two transactions read first and then update a data resource. Using shared locks or exclusive locks will cause deadlocks, which can be avoided by using update locks. The update lock of the resource can only be assigned to one transaction in turn. Any modification to the resource will be programmed as an exclusive lock, otherwise the lock will be shared.

  <4>. Intention lock: acquire shared locks, exclusive locks, and update locks on the underlying resources (rows, tables) of the hierarchical structure. For example, preventing intentional shared locks at the table level means that a transaction needs to use shared locks on the pages or rows of the table. Placing an intent lock on a row of a table can place other transactions that acquire other incompatible locks. It improves performance because the database engine does not need to examine every row and every column of a resource to determine whether a compatible lock can be acquired for that resource. Intention shared lock, intention exclusive lock, intention exclusive shared lock.

  <5>. Schema lock: Place a lock for concurrent access when modifying the table structure.

  <6>. Large-capacity update lock: Allows multiple counties to plan to migrate a large amount of data to the same data table concurrently, and does not allow other threads to access the table during loading.

 

Among the above six locks, 1.2.3 is the most frequently used. General database transaction read operations use shared locks, while write operations use exclusive locks, depending on the specific business.

 

4. Deadlock

Deadlock means that a transaction locks a resource without releasing it, causing other transactions to fail to use the resource and the system waits for congestion or crashes due to timeout.

Scenarios that appear:

 step1. Transaction A: first update table a - delay 1s - update table b

 step2. At the same time there is transaction B: first update table b - delay 1s - update table a

 step3. Execute transactions A and B at the same time within 1s, and a deadlock occurs.

 Because during the delay of 1s, the transaction adds exclusive lock 1 when updating a. When updating b, it requests the exclusive lock 2 of b, and b already occupies the exclusive lock 2. At the same time, updating a also requests the exclusive lock of a. Lock 1, in the case of waiting for each other and the two transactions are unwilling to release their respective locks, they will always wait for this infinite loop.

 Of course, there is no infinite wait in the database, because the database engine will regularly detect that once there is a deadlock, it will solve the problem by releasing the occupied lock at the cost of a transaction according to certain rules. The sacrificed transaction is rolled back.

 Deadlock sacrifice rules, it is considered that the priority can be set, and the lower priority sacrifices first. Random with the same priority.

 

Deadlock is a culprit that consumes a lot of time and resources. In large-scale system applications, although it cannot be avoided, SQL should be optimized as much as possible to reduce deadlocks:

  <1> The update lock does not regret the occurrence of deadlock.

  <2> In a transaction, try not to deal with too much complex logic.

  <3> Set the transaction to commit automatically.

  <4> Reduce concurrent database access.

  <5> Use partition tables and views. Distribute data resources by placing data on different disks or filegroups.

  <6> When designing the table, optimize the logic and do not make it too complicated.

  <7> The transaction isolation level should be as low as possible.

In actual production, instead of passively waiting for the deadlock check mechanism of the database itself to deal with deadlocks, you can actively set the timeout period, which not only handles deadlocks, but also actively cancels transactions due to waiting time timeouts caused by other reasons. Free up resources. And manually roll back the logic at this time in the program to ensure data consistency.

 

5. Transaction isolation level

The degree to which a transaction is isolated from resource and data changes made by other transactions. Isolation levels describe database transactions in terms of allowing concurrent side effects.

  1) read uncommittde: uncommitted read, the lowest isolation level, A transaction can read the B transaction is changing the data that has not been committed. Dirty reads corresponding to locks.

  2) read committed: committed read, which is the default isolation level of sql, transaction A can only read the data before or after transaction B is committed. Dirty reads do not occur, but phantom reads occur, which are non-repeatable reads.

  3) Repeatable read: Repeatable read, cannot read the data being processed by the transaction, nor can it modify the data being processed by the transaction, no dirty reads, non-repeatable reads, but phantom reads.

  4) Serialization: Serialization, the highest transaction isolation level, one thing locks the entire data table so that only the data before the transaction can be seen. Dirty reads, non-repeatable reads, and phantom reads will not occur.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=326309405&siteId=291194637