https://www.cnblogs.com/wodebudong/articles/7976474.html
Recently encountered a case of the lock table, find where to retrieve the updated statement of the field, did not build the index, and the bulk of the operation, there have been cases of the lock table.
So there are two questions:
-
Indexing and indexing does not impact on the lock table
-
Why batch update will lock table
1. The construction of the index and not indexing, the impact on the lock table
1. 2. indexed and non-indexed
Introduction premise:
Mode: using the command line to simulate
1.mysq automatically commit the transaction because the transaction is enabled by default auto-commit, so first of all have to see if your current database opens.
Command: select @@ autocommit;
The results are as follows:
+--------------+
| @@autocommit |
+--------------+
| 0 |
+--------------+
If it is 1, then run the command: set autocommit = 0; set not to enable auto-commit
2. The current database table format
tb_user | CREATE TABLE `tb_user` (
`id` bigint(20) NOT NULL AUTO_INCREMENT,
`name` varchar(32) DEFAULT NULL,
`phone` varchar(11) DEFAULT NULL,
`operator` varchar(32) DEFAULT NULL,
`gmt_create` datetime DEFAULT NULL,
`gmt_modified` datetime DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8
Obviously in addition to the primary key, I did not add any indexes
Practical examples:
1. There is no index
Run the command: begin; open transaction, and then run the command: update tb_user set phone = 11 where name = "c1"; modify, first do not commit the transaction.
To open a window, run the command directly: update tb_user set phone = 22 where name = "c2"; find command stuck, but the current side has submitted a transaction commit, the command will end the normal operation, indicating that the lock the table.
2. Give the name field indexed
create index index_name on tb_user(name);
Then continue as an inside operation, that is to open a business, run update tb_user set phone = 11 where name = "c1"; to not submit
Then another run update tb_user set phone = 22 where name = "c2"; discovery command does not catch, the lock table is not described
However, if another also update tb_user set phone = 22 where name = "c1"; update the same row, indicating that the lock line
3. Summary
mysql row lock is loaded by the index, i.e., a lock is applied to the row line in response to the index, if the SQL statement corresponding to the index did not take, it will scan the entire table,
Row lock can not be achieved, replaced by a table lock.
In short: there where conditions, when no index, update using the "lock table" update query update affect all rows;
After the addition of the index, using the "Line Lock" in udpate, only lock the current line. Update query does not affect other lines.
2. Why batch updates lock table
Because batch update, because the table is not indexed, it will retrieve the entire table lead to very slow to update, and each update sql commit the transaction has a timeout limit, after the submission of the transaction to wait for the transaction to release the lock of the front handle, but in waiting when more than mysql lock wait time, an exception is thrown causing table locks: lock wait timeout exceeded; try restarting transaction
SHOW VARIABLES LIKE 'innodb_lock_wait_timeout'
innodb_lock_wait_timeout参数为超时时间的设置，默认为50，可以设大点，但并不能解决问题;所以加索引，或者优化代码；