part1:
Differences in the implementation of indexes and locking mechanisms between the two storage engines
Multi-column index in MySql.
1) Joint index is also called compound index. For compound indexes: Mysql uses the fields in the index from left to right. A query can only use a part of the index, but only the leftmost part. For example, the index is key index (a,b,c). It can support three combinations of a | a, b| a, b, c for search, but does not support b, c for search. When the leftmost field is a constant reference , the index is very efficient.
2) Multi-column indexing is more advantageous than indexing each column separately, because the more indexes are established, the more disk space is occupied, and the speed will be slower when updating data. In addition, when creating a multi-column index, the order also needs to be paid attention to. The strict index should be placed in the front, so that the screening force will be stronger and the efficiency will be higher.
3) The effective principle of the combined index is to use it in sequence from the front to the back. If an index in the middle is not used, the index part before the breakpoint will work, and the index after the breakpoint will not work; for example, where a=3 and b= 45 and c=5 .... There is no breakpoint in the middle of the three index sequences, and they all work; where a=3 and c=5... In this case, b is the breakpoint, and a has an effect. c has no effect where b=3 and c=4... In this case, a is a breakpoint, and the index after a has no effect. This combination of indexing has no effect; where b=45 and a= 3 and c=5 .... This is the same as the first one, it all works, as long as abc is used, it has nothing to do with the order of writing
Also note that (a,b,c) multi-column indexes are not the same as (a,c,b)
(0) select * from mytable where a=3 and b=5 and c=4; all three indexes abc are used in the where condition, and they all play a role (1) select * from mytable where c=4 and b =6 and a=3; This statement is listed only to show that mysql is not that stupid, the order of conditions in where will be automatically optimized by mysql before querying, the effect is the same as the previous sentence (2) select * from mytable where a=3 and c=7; a uses the index, b is useless, so c does not use the index effect (3) select * from mytable where a=3 and b>7 and c=3; a is used, and b is also used Here, c is not used, where b is a range value, and it is also a breakpoint, but it uses the index itself (4) select * from mytable where b=3 and c=4; because the a index is not used, so here bc No index effect is used (5) select * from mytable where a>4 and b=7 and c=9; a is used b is not used, c is not used (6) select * from mytable where a=3 order by b ;a uses the index, and b also uses the effect of the index in the result sorting. As mentioned earlier, the b in any paragraph below a is sorted (7) select * from mytable where a=3 order by c; a uses The index is reached, but c does not play a sorting effect in this place, because there is an intermediate breakpoint, use explain to see filesort (8) select * from mytable where b=3 order by a; b does not use the index, nor does a in the sorting play index effect
4) Then if we create two column indexes on a and b respectively, the processing method of mysql is different. It will select the most stringent index for retrieval, which can be understood as the index with the strongest retrieval ability. , the other one cannot be used, so the effect is not as good as multi-column index.
part2:
Locks in MySQL (pessimistic locking, optimistic locking)
Locks in MySQL (table locks, row locks)
MySQL shared locks and exclusive locks
MySQL pessimistic lock and optimistic lock summary and practice
Java CAS and ABA issues
CAS principle analysis
Non-blocking synchronization algorithm and CAS (Compare and Swap) lock-free algorithm
The mysql lock mechanism is divided into table-level locks and row-level locks. This article will share with you my sharing and exchange of shared locks and exclusive locks in row-level locks in mysql.
Shared locks are also called read locks, or S locks for short. As the name suggests, shared locks are multiple transactions that can share a lock on the same data and can access the data, but they can only be read and cannot be modified.
The select language is not locked. If you want to add a shared lock, select * from table where id=1 in share mode; after adding a shared lock, other things can still pass select * from table where id=1; or select * from table where id=1 in share mode; the data is queried, but the operations such as update, insert, and delete add an exclusive lock by default. Exclusive locks cannot coexist with other locks. If an exclusive lock has been added to a row, other locks such as exclusive locks or shared locks will be blocked.
Exclusive locks are also called write locks, or X locks for short. As the name implies, exclusive locks cannot coexist with others. For example, if a transaction acquires an exclusive lock on a data row, other transactions cannot acquire other locks on the row, including shared locks. and exclusive locks, but the transaction that acquires the exclusive lock can read and modify the data.
对于共享锁大家可能很好理解，就是多个事务只能读数据不能改数据，对于排他锁大家的理解可能就有些差别，我当初就犯了一个错误，以为排他锁锁住一行数据后，其他事务就不能读取和修改该行数据，其实不是这样的。排他锁指的是一个事务在一行数据加上排他锁后，其他事务不能再在其上加其他的锁。mysql InnoDB引擎默认的修改数据语句，update,delete,insert都会自动给涉及到的数据加上排他锁，select语句默认不会加任何锁类型，如果加排他锁可以使用select ...for update语句，加共享锁可以使用select ... lock in share mode语句。所以加过排他锁的数据行在其他事务种是不能修改数据的，也不能通过for update和lock in share mode锁的方式查询数据，但可以直接通过select ...from...查询数据，因为普通查询没有任何锁机制。
part3: