Do I need to lock the SELECT...WHERE id=100 statement with a unique index?

MySQL's default transaction level, REPEATABLE READ, is based on the following behavior:

<li> A read system is executed for snapshot (like a reference copy of a table) at a specific point of time.I'm not looking at the latest table status, so I don't need to lock it.
• The update system is now running on the latest table, and updates made by that transaction will not be overwritten by any other transaction until the transaction is finished

In order to have this characteristic, especially in the update system, MySQL uses various locks provided by InnoDB for where clauses of update and delete.If anything, the table in which the transaction has been updated is locked until the transaction is finished to satisfy the nature of the update system of REPEATABLE READ.

So the next keylock or gaplock talk in the first half of the question is basically "If you want to issue a key scan to lock." For example, if the id is a primary key (that is, a type of unique index), the update below does not get a gap lock if the id=100 record exists.

UPDATE table_name SET name='new_name'WHERE id=100;

Now, the reason why SELECT statements are used as examples in these locks is that SELECT statements can get locks similar to the update system in the following cases:

• SELECT...FROM...FOR UPDATE syntax
  • SELECT...FROM...FOR UPDATE is a read-locked version of SELECT...FROM...LOCK IN SHARE MODE syntax
• SERIALIZABLE Transaction Level Simple SELECT...FROM... Syntax.
  • SELECT...FROM...LOCK IN SHARE MODE is automatically converted

• SELECT...FROM...FOR UPDATE is a read-locked version of SELECT...FROM...LOCK IN SHARE MODE syntax

• SELECT...FROM...LOCK IN SHARE MODE is automatically converted

To sum up:

• A description of cases where a gap lock is obtained or not obtained is from
• When you run a scan to run the lock
• SERIALIZABLE allows simple SELECT statements to be LOCK IN SHARE MODE on their own, so scanning without locking is not performed
• REPEATABLE READ When operating at a transaction level below, whether the lock is acquired depends on the type of SQL statement and transaction level being executed, and what lock is acquired depends on the SQL statement and transaction level and what the actual data is.The question gap lock description explains some of the logic behind how this lock is determined.