Two types of locking problems in MySQL

MySQL describes two problems in 15.2.10.5, and gives the solution separately.
1. Write the data to the child table, but before writing, make sure that its corresponding information exists in the parent table.
It may appear that the data in the parent table has been read, but another request is deleted.
Way:

Begin;select info from father_table where name = ' Nike ' LOCK in SHARE mode;insert into son_table values (' someinfo '); commit ;

A transaction is a process that ensures atomicity of multiple processes, but does not guarantee the correctness of the above problems. In the transaction, the lock in SHARE MODE is used,
It sets a shared lock on the line we read so that the latest data can be read, and when you access a data that has the same shared lock,
Waits for the transaction to be committed before it is read. This avoids the problem that the data is modified when a transaction is not completed.

2. When a counter is implemented, the same field is modified, and when both users read and then modify it, a process may
Another process reads the data and writes the data again, so that a statistic is omitted.
Way:
1. Write data, write data lock, and read data is limited, only when the data added up, to read, and after the addition, it is the latest data.
2.

Begin;select count Form son_table for update;update son_table Set count = Count + 1;commit;

SELECT ... The for update reads the most recent visible data, setting an exclusive lock on each row it reads. Therefore, it sets the same lock as the lock that the search SQL update may set on the row.

The above example shows that when multiple users access the same row of data, a lock may occur, whereas a single user accessing only his own data is unlikely to lock up, for example, to modify a profile

Two types of locking problems in MySQL