Questions about mysql locks

What is the concept of a mysql database and a table for users? If user A locks A table, user B will be affected by the lock, right? If yes, in a website, all operations on the database are performed by the same user, will the lock still work at this time? If not, what should I do? What is the concept of a mysql database and a table for users? If user A locks A table, user B will be affected by the lock, right?
If yes, in a website, all operations on the database are performed by the same user, will the lock still work at this time?
If not, what should I do?

Reply content:

What is the concept of a mysql database and a table for users? If user A locks A table, user B will be affected by the lock, right?
If yes, in a website, all operations on the database are performed by the same user, will the lock still work at this time?
If not, what should I do?

The lock is for the request.
MySQL table locks are divided into read locks and write locks, which are mainly maintained through four Queues: two stores the read/write locks in the locked state, and two stores the read/write locks in the waiting state.

As follows: • Current read-lock queue (lock-> read) • Pending read-lock queue
(Lock-> read_wait) • Current write-lock queue (lock-> write) • Pending
Write-lock queue (lock-> write_wait) the information of all threads currently holding the read lock can be
The read-lock queue is found, and the information in the queue is stored in sequence according to the time when the lock is obtained. The information waiting to lock the resource is stored in Pending.
In the read-lock queue, the other two queues that store the write lock information also store the information according to the same rules above.

When requesting to obtain a read lock resource, a new client request must meet two conditions: 1. The requested resource is not currently locked by write;
2. write lock wait queue (Pending write-lock queue) with no higher priority;
If the preceding conditions are met, the request will be passed immediately and the relevant information will be saved to the Current read-lock queue.
And if either of the above conditions is not met, it will be forced to enter the waiting queue Pending read-lock queue to wait for the release of resources. Write lock
When the client requests a write lock, MySQL first checks whether information of the same resource source has been locked in the Current write-lock queue.
If the Current write-lock queue does not exist, check the Pending write-lock queue.
Pending write-lock queue is found. You also need to enter the waiting queue and pause your thread to wait for the resource to be locked. If Pending
If the write-lock queue is empty, check the Current read-lock queue again. If the lock exists, enter
Pending write-lock queue wait. Of course, you may also encounter the following two special cases:

1. The requested lock type is WRITE_DELAYED;

2. The type of request lock is WRITE_CONCURRENT_INSERT or TL_WRITE_ALLOW_WRITE, and Current read lock is the lock type of READ_NO_INSERT.
   In these two special cases, the write lock will be obtained immediately and enter the Current write-lock queue.

The Current write-lock queue already has a write lock that locks the same resource, so you can only wait for the queue to wait for the release of the corresponding resource lock.
The priority rules of write lock requests in read requests and write wait queues are determined by the following rules:

1. In addition to READ_HIGH_PRIORITY, write WRITE locks in Pending write-lock queue can block all other read locks;

2. READ_HIGH_PRIORITY read lock requests can block write locks in all Pending write-lock queue;

3. In addition to WRITE lock, any write lock in the Pending WRITE-lock queue has a lower priority than read lock. After the write lock is determined to be Current write-lock queue, all other locked requests except the following conditions will be blocked:

4. Some storage engines allow a WRITE_CONCURRENT_INSERT write lock request.

5. When the write lock is set to WRITE_ALLOW_WRITE, all read and write lock requests except WRITE_ONLY are allowed.

6. When the write lock is set to WRITE_ALLOW_READ, all read lock requests except READ_NO_INSERT are allowed.

7. When the write lock is set to WRITE_DELAYED, all read lock requests except READ_NO_INSERT are allowed.

8. When the write lock is set to WRITE_CONCURRENT_INSERT, all read lock requests except READ_NO_INSERT are allowed.

The lock is used to solve the competition problem when multiple processes process the same data at the same time.

The minimum lock granularity of the InnoDB engine is Row-level locks. When two requests modify a row of records at the same time, the transaction will be locked upstream.

It has nothing to do with users who are not users.

A lock table is used for database data tables. If a table is locked, the table cannot be accessed.