If transactions are not taken into account, SQL 1 is simple (no lock). What should I do if a query operation and a write operation are executed at the same time? Will mysql automatically lock the transaction? 2: What if two or more query operations are performed at the same time? 3: What if two write operations are executed at the same time? 3:... a simple (no lock) SQL statement without considering transactions
1: What if a query operation and a write operation are executed at the same time? Will mysql automatically lock it?
2: What if two or more query operations are performed at the same time?
3: What if two write operations are executed at the same time?
3: What if one read and one write at the same time?
Transactions are not considered.
Reply content:
Without consideration of transactions, it is simply a normal (no lock) SQL statement.
1: What if a query operation and a write operation are executed at the same time? Will mysql automatically lock it?
2: What if two or more query operations are performed at the same time?
3: What if two write operations are executed at the same time?
3: What if one read and one write at the same time?
Transactions are not considered.
To answer:
1: There are no locks for different select statements in innodb, and Myisam will automatically add table share read locks;
2: innodb has no locks, so there is no problem. Myisam is a table shared read lock. The shared read locks do not conflict with each other and are parallel;
3: Myisam is the exclusive write lock for tables. Table-level locks are serial. Write locks are blocked. The SQL statements that must be written are executed one by one. The innodb situation is a little complicated. innodb uses the row lock, which is also related to the index (which affects the locking) and will automatically apply the row exclusive lock:
Exclusive lock (X): allows transactions that obtain exclusive locks to update data, and prevents other transactions from obtaining shared read locks and exclusive write locks for the same dataset.
So if there is no row lock conflict, there will be no impact on each other, otherwise there will be lock blocking.
The lock granularity may also lead to deadlocks, that is, mutual lock wait will lead to deadlocks. When a transaction finds that it has to wait for the lock to be released, it also waits for it to release the lock, it will cause a deadlock to exit, release the lock, and let the former get the lock;
4: for general SELECT statements, InnoDB does not apply any locks, so there is no problem in reading and writing at the same time. Reading is a snapshot read and writing is the current read. For Myisam, which process obtains the table lock first, read/write is serialized.
Reference: http://blog.csdn.net/xifeijian/article/details/20313977
Reference: http://blog.csdn.net/xifeijian/article/details/20312557
Automatic lock, update is an atomic operation