Global lock
1, the global lock locks the entire database instance, Flush tables with read lock (FTWRL).
2. After using the global lock, the database is in a read-only state, and the addition, deletion, and modification of data update statements, data definition statements to create tables and modify table structures, and update transaction submission statements will all be blocked.
3. The global lock is applied to the logical backup scenario of the entire database, and the entire database is selected and saved as text.
1) If it is backed up on the main library, the business will basically stop during the backup period;
2) If it is backed up on the slave library, the binlog of the master library synchronization cannot be executed during the backup period, resulting in master-slave delay.
3) If it is not locked, the library obtained from the backup is not at the same logical time point.
4. Open the transaction under the repeatable read isolation level to ensure a consistent view, and the data can be updated normally during the backup process.
1) The official logical backup tool mysqldump, when mysqldump uses the parameter single-transaction, start the transaction before importing data.
2) The single-transaction method applies to all tables using libraries that support transaction engines.
3) MyISAM engine does not support transactions, only FTWRL can be used in backup.
5. The whole library is read-only, you can set set global readonly=true, but it is not suitable for backing up the whole library.
1) In some systems, readonly is also used to judge the main and standby databases, and modifying global variables has a greater impact.
2) If the client is abnormal during the backup process, the database will remain in the readonly state, causing the entire database to be in an unwritable state for a long time, and the risk is too high.
3) If the FTWRL client is abnormally disconnected, MySQL will automatically release the global lock, and the entire database can return to the normal update state.
Table lock
1, there are two types of table-level locks: one is a table lock, and the other is a metadata lock (meta data lock, MDL). Table-level locks are used when the engine does not support row locks.
2. Table lock lock tables ... read/write, which restricts the current thread and other threads from reading and writing to the table.
1) read t1 The current thread only reads t1, and other threads only read t1;
2) Write t2 The current thread reads and writes t2, and other threads cannot read and write t2;
3) Other tables cannot be accessed;
4) Similar to FTWRL, unlock tables are actively released The lock will be released automatically after the client disconnects.
3. The metadata lock does not need to be used explicitly, it is automatically added when accessing the table, and the role of MDL is to ensure the correctness of reading and writing.
1) Add an MDL read lock when adding, deleting, modifying and querying the table, and add an MDL write lock when changing the table structure.
2) Read locks are not mutually exclusive, and read-write and write locks are mutually exclusive, ensuring the security of the change table structure.
3) When related statements are executed in a transaction, the system automatically adds an MDL lock, which will not be released immediately after the statement ends, and the MDL lock will be released only after the transaction is committed.
4) If the long transaction does not commit and occupies the MDL read lock, the write lock will be blocked, and the read lock after the write lock will also be blocked, making the table unreadable. If the client has a retry mechanism, the library's threads will easily be full.
5) Set the waiting time WAIT N in the alter table statement. If the MDL write lock is obtained during the waiting time, the table change will be executed. If the write lock is not obtained, the subsequent business will not be blocked, and the process can be repeated afterward. .
Row lock
1. Row locks are implemented by the engine layer. The MyISAM engine does not support row locks, and only table locks can be used to control concurrency.
2. In an InnoDB transaction, a row lock is added when the statement is updated, the lock is not released at the end of the statement, and the row lock is released after the transaction ends, which is a two-stage lock.
3. When different threads in concurrency have circular resource dependencies, the involved threads are waiting for other threads to release resources, causing the threads to enter an infinite waiting state, which is called deadlock. After a deadlock occurs,
1) One strategy is to wait until the timeout, innodb_lock_wait_timeout sets the timeout period.
2) One strategy is to initiate deadlock detection, find a deadlock, actively roll back a transaction in the deadlock linked list, so that other transactions can continue to execute, and set the parameter innodb_deadlock_detect to on, indicating that deadlock detection is enabled.
3) The default value of innodb_lock_wait_timeout is 50s, and the waiting time is longer. After setting it to a small value, a deadlock can be solved quickly, but if it is not a deadlock, but only the waiting time of the lock, it will be accidentally injured.
4) Using the deadlock detection strategy, each transaction is locked, and it is necessary to detect whether other threads that depend on it are locked, and so on, and finally judge whether there is a circular wait. Even if the detection result is not deadlocked, the detection process consumes a lot of time CPU resources, although the CPU utilization rate is high, it can't execute a few transactions per second.
4. A better idea is to enable deadlock detection and control the amount of concurrency, roll back when a deadlock occurs, and then retry the business, which is non-destructive to the business.
1) If deadlock detection is turned off, a large number of timeouts may occur, which will damage the business;
2) The cost of controlling concurrency deadlock detection is relatively low, and the database server should do a good job of concurrency control.
5. It is also possible to modify the logic of a row to logically multiple rows to reduce lock conflicts.
1) Design a row of data as the sum of multiple rows of records, and optionally update a row of data randomly to reduce the probability of conflict.
2) If there is middleware, it can be implemented in the middleware, or the MySQL source code can be modified, and the update of the same row is queued before entering the engine, so there will not be a large number of deadlock detections inside InnoDB.
3) If multiple rows need to be locked in a transaction, the row locks that are most likely to cause conflicts and affect concurrency should be put back.
6. Example: If you want to delete the first 10,000 rows of data in a table:
1) Execute delete from T limit 10,000 directly. A single statement takes a long time, and the lock time is also relatively long. If it is a large transaction, it will cause master-slave delay.
2) It is relatively good to execute delete from T limit 500 20 times in a connection cycle.
3) Executing delete from T limit 500 in 20 connections at the same time will artificially cause lock conflicts.