One: Affairs:
We all know that a transaction is a logical unit in a database management system, composed of a limited sequence of operations, and the most famous is its ACID 4 attributes.
Atomicity, the operations contained in the transaction are either all executed; or all are not executed.
Consistency, the data in the database should satisfy integrity constraints.
Isolation, the execution of a transaction in the database should not affect other transactions.
Durability, the committed transaction (state), its modification to the database, etc. should be permanently stored in the database.
Transaction usage
1) At the beginning of the transaction, there are two ways of writing:
1）BEGIN; 2) BEGIN TRANSACTION;
2) The transaction ends, there are two situations:
1) COMMIT;-confirm the transaction 2) ROLLBACK;-roll back the transaction
For test analysts, the concept of transaction can also be applied to analysis problems. For example, if you want to analyze the execution plan of an update/insert/delete SQL statement, then you can use the concept of transaction to better manage our database data.
We want to analyze the execution plan of the following SQL:
delete from public."Department" where "DepID" = '1';
Then it can be executed as follows:
begin; explain analyze delete from public."Department" where "DepID" = '1';
The execution plan of the delete SQL statement is obtained above, but you don't want to actually delete the data, you can continue to execute the following statement:
rollback;
Two: lock
The concept of lock in Postgresql is consistent with most relational databases, and is to meet the purpose of data consistency in transactions. Generally, in a database with high concurrency, if it is not controlled, data reading and storage may be inconsistent.
1) Deadlock. If two transactions are waiting for each other to complete the transaction, then it is very likely that a deadlock will occur. When a deadlock occurs, postgresql will automatically detect them and roll back all related transactions to end them. Ensuring that the program should lock the objects in the same order can effectively avoid deadlocks.
2) Second, the division of lock types can be divided into table-level locks and row-level locks. The two most common locks are the Share and Exclusive locks. Share refers to the read lock, that is, the content of the table cannot be modified. This lock can be added to multiple transactions, but if any transaction does not release the lock, then the content of the table cannot be modified; Exclusive is table-level The write lock is locked. If the transaction that acquired the lock is not released, then other transactions cannot read or write. Of course, a multi-version mechanism (MVCC) was introduced later. This situation has been improved, with 2 more locks, Access Share/Access Exclusive. The database operation corresponding to Access Share is generally select operation statement; the database operation corresponding to Access Exclusive is generally alter table/drop table/truncate/reindex/vacuum full, etc.
How to better avoid resource contention and other issues can be reasonably avoided by considering the following aspects.
1) When processing some shared resources with high concurrency, you can consider shifting the focus of this pressure from relational databases to in-memory NO-SQL databases, such as redis. The front-end can consider the realization of business requirements such as multi-threading and high concurrency, while the key back-end can use the native single-threaded processing mode that comes with redis, and its execution efficiency is not necessarily bad.
2) Use resources in the same order in all database transactions.
3) Try to use a lower isolation level.
You can also scan and follow the WeChat official account to get more performance-related content:
