Locked record issue when MYSQL Select

When using SQL, most of the time, when you update a record, you need to retrieve its value or condition through Select, and then perform the modification by this value.

However, the problem occurs when the above operations are placed concurrently in multi-threaded processing: A thread selects a record but before it can update, another thread may still come in to select the same record.

The general solution is to use a joint mechanism of locks and things :

Such as:

1. PutSelect is placed in the transaction,otherwise , the select completes and the lock is released. 。
2. To block another select, to manually lock , select By default is a shared lock , the shared lock between select is not conflicting , so , If the lock is shared only , the other select can share the lock, even if the lock is not released, and Select out the data .

BEGIN TRAN
SELECT * from table with (TABLOCKX)

or SELECT * from table with (UPDLOCK, READPAST) specific case.

UPDATE ....
COMMIT TRAN

Lock Description:
HOLDLOCK: Preserves a shared lock until the transaction completes, rather than releasing the lock immediately when the corresponding table, row, or data page is no longer needed.HOLDLOCK is equivalent toSERIALIZABLE.
NOLOCK do not issue a shared lock, and do not provide an exclusive lock. When this option is in effect, it is possible to read uncommitted transactions or a set of pages that are rolled back in the middle of the read. Dirty reads may occur. Apply only toSELECT statement.
Paglock: page locks are used where a single table lock is normally used.
ReadCommitted: Performs the scan with the same lock semantics as the transaction running at the Read isolation level. By default,SQL Server 2000 operates at this isolation level.
READPAST: Skips locking lines. This option causes the transaction to skip rows that are locked by other transactions, which are normally displayed in the result set, rather than blocking the transaction so that it waits for other transactions to release locks on those rows.The READPAST lock hint is only available for transactions that run at the commit read isolation level, and is read only after row-level locks. Only available forSELECT statement.
ReadUncommitted: Equivalent toNOLOCK.
RepeatableRead: Performs the scan with the same lock semantics as the transaction running at the REPEATABLE read isolation level.
Rowlock: Use row-level locks instead of coarser-grained page-level and table-level locks.
SERIALIZABLE: Performs a scan with the same lock semantics as transactions running at the serializable isolation level. Equivalent to HOLDLOCK.
TABLOCK: Use table locks instead of finer-grained row-level or page-level locks. SQL Server holds the lock until the end of the statement. However, if you specify HOLDLOCK at the same time, the lock will be held until the end of the transaction.
Tablockx uses the table's exclusive lock. The lock prevents other transactions from reading or updating the table and holding it until the end of the statement or transaction.
UPDLOCK: Use an update lock when reading a table instead of a shared lock and keep the lock until the end of the statement or transaction. UPDLOCK: The advantage is that it allows you to read data (without blocking other transactions) and update the data at a later time, while ensuring that the data has not been changed since the last time the data was read.
XLOCK: Uses an exclusive lock and remains until the end of a transaction on all data processed by the statement. the lock can be specified using Paglock or TABLOCK, in which case the exclusive lock applies to the granularity of the appropriate level.

Locked record issue when MYSQL Select