database - ghdrako/doc_snipets GitHub Wiki
Build
Ranking:
Being absolutely correct on their own, transactions can start operating incorrectly when run in parallel. That’s because operations belonging to different transactions often get intermixed. There would be no such issues if the database system first completed all operations of one transaction and then moved on to the next one,but performance of sequential execution would be implausibly low.
Correct transactions that behave incorrectly when run together result in concurrency anomalies, or phenomena.
When running transactions concurrently, the database must guarantee that the result of such execution will be the same as the outcome of one of the possible sequential executions. In other words, it must isolate transactions from one another, thus taking care of any possible anomalies.
A transaction is a set of operations that takes the database from one correct state to another correct state (consistency), provided that it is executed in full (atomicity) and without being affected by other transactions (isolation). This definition combines the requirements implied by the first three letters of the ACID acronym.
The SQL standard specifies four isolation levels.1 These levels are defined by the list of anomalies that may or may not occur during concurrent transaction execution.So when talking about isolation levels, we have to start with anomalies.
The great extent the difference between the standard isolation levels is defined by the number of locks required for their implementation.
- If the rows to be updated are locked for writes but not for reads, we get the
Read Uncommitted
isolation level, which allows reading data before it is committed. - If the rows to be updated are locked for both reads and writes, we get the
Read Committed
level: it is forbidden to read uncommitted data, but a query can return different values if it is run more than once (non-repeatable reads). - Locking the rows to be read and to be updated for all operations gives us the
Repeatable Read
level: a repeated query will return the same result. - the
Serializable
level poses a problem: it is impossible to lock a row that does not exist yet. It leaves an opportunity for phantom reads to occur: a transaction can add a row that satisfies the condition of the previous query, and this row will appear in the next query result.
Lock-based protocols for transaction management got replaced with the Snapshot Isolation (SI)
protocol.Snapshot isolation minimizes the number of required locks. In fact, a row will be locked only by concurrent update attempts. In all other cases, operations can be executed concurrently: writes never lock reads, and reads never lock anything.
Multiversion concurrency as flawer of Snapshot Isolation control implies that at any moment the database system can contain several versions of one and the same row.
Query optimizer
- https://xuanwo.io/2024/02-what-i-talk-about-when-i-talk-about-query-optimizer-part-1/
- https://news.ycombinator.com/item?id=39176797