A few days before the fault description , a mysql database operation and maintenance colleague used the insert into select from statement in production to back up a table in production. As a result, the entire backup table was locked, and the business affected about 10 minutes.
Seeing this statement, my first reaction is that the select statement can also lock the table, but the failure in production proves that the table is indeed locked. Therefore, it is necessary to thoroughly study the situation of insert into select from acquiring locks.
Fault review to
create analog tables and analog records
[root@localhost] 17:39:55 [testdb1]>show create table t_test_1\G;
*************************** 1. row ***************************
Table: t_test_1
Create Table: CREATE TABLE `t_test_1` (
`id` int(11) NOT NULL,
`name` char(10) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '',
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci
1 row in set (0.00 sec)
[root@localhost] 17:40:30 [testdb1]>select * from t_test_1;
+----+-------+
| id | name |
+----+-------+
| 1 | trest |
| 2 | e99e |
| 3 | test |
| 4 | fresd |
| 5 | fsfa |
+----+-------+
5 rows in set (0.00 sec)
[root@localhost] 17:40:17 [testdb1]>show create table t_test_2\G;
*************************** 1. row ***************************
Table: t_test_2
Create Table: CREATE TABLE `t_test_2` (
`id` int(11) NOT NULL,
`name` char(10) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '',
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci
1 row in set (0.00 sec)Simulate insert into select operation
[root@localhost] 17:41:32 [testdb1]>begin;
Query OK, 0 rows affected (0.00 sec)
[root@localhost] 17:41:33 [testdb1]>insert into t_test_2 select * from t_test_1 where name like 'trest';
Query OK, 1 row affected (0.02 sec)
Records: 1 Duplicates: 0 Warnings: 0Get lock information of innodb
[root@localhost] 17:42:00 [(none)]>show engine innodb status\G;
TRANSACTIONS
------------
Trx id counter 182551
Purge done for trx's n:o < 182551 undo n:o < 0 state: running but idle
History list length 0
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 421524582451936, not started
0 lock struct(s), heap size 1136, 0 row lock(s)
---TRANSACTION 182546, ACTIVE 20 sec
3 lock struct(s), heap size 1136, 6 row lock(s), undo log entries 1
MySQL thread id 7, OS thread handle 140049254979328, query id 82 localhost rootThe lock information obtained from the innodb engine is too small. I can only see 3 lock struct(s) and 6 row lock(s). I don’t know the lock applied for in that table, and what type of lock is applied for. I don’t know this information. Just research and don't understand how the failure happened.
Fortunately, mysql database provides a parameter innodb_status_output_locks, which can print more detailed lock information.
Enable the innodb_status_output_locks parameter to
enable the innodb_status_output_locks parameter, which is not enabled by default, so it needs to be enabled.
[root@localhost] 17:31:12 [(none)]>show variables like 'innodb_status_output_locks';
+----------------------------+-------+
| Variable_name | Value |
+----------------------------+-------+
| innodb_status_output_locks | OFF |
+----------------------------+-------+
1 row in set (0.00 sec)
[root@localhost] 17:47:41 [(none)]>set global innodb_status_output_locks=on;
Query OK, 0 rows affected (0.00 sec)
[root@localhost] 17:47:41 [(none)]>show variables like 'innodb_status_output_locks';
+----------------------------+-------+
| Variable_name | Value |
+----------------------------+-------+
| innodb_status_output_locks | ON |
+----------------------------+-------+
1 row in set (0.00 sec)Get
the detailed lock information of InnoDB. The following is the detailed lock information obtained after the innodb_status_output_locks parameter is turned on
[root@localhost] 17:48:28 [(none)]>show engine innodb status\G;
TRANSACTIONS
------------
Trx id counter 182552
Purge done for trx's n:o < 182551 undo n:o < 0 state: running but idle
History list length 0
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 421524582451936, not started
0 lock struct(s), heap size 1136, 0 row lock(s)
---TRANSACTION 182551, ACTIVE 5 sec
3 lock struct(s), heap size 1136, 6 row lock(s), undo log entries 1
MySQL thread id 11, OS thread handle 140049254979328, query id 100 localhost root
TABLE LOCK table `testdb1`.`t_test_1` trx id 182551 lock mode IS
RECORD LOCKS space id 97 page no 3 n bits 72 index PRIMARY of table `testdb1`.`t_test_1` trx id 182551 lock mode S
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
0: len 8; hex 73757072656d756d; asc supremum;;
Record lock, heap no 2 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
0: len 4; hex 80000001; asc ;;
1: len 6; hex 00000002c710; asc ;;
2: len 7; hex af000000310110; asc 1 ;;
3: len 10; hex 74726573742020202020; asc trest ;;
Record lock, heap no 3 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
0: len 4; hex 80000002; asc ;;
1: len 6; hex 00000002c710; asc ;;
2: len 7; hex af00000031011c; asc 1 ;;
3: len 10; hex 65393965202020202020; asc e99e ;;
Record lock, heap no 4 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
0: len 4; hex 80000003; asc ;;
1: len 6; hex 00000002c710; asc ;;
2: len 7; hex af000000310128; asc 1 (;;
3: len 10; hex 74657374202020202020; asc test ;;
Record lock, heap no 5 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
0: len 4; hex 80000004; asc ;;
1: len 6; hex 00000002c710; asc ;;
2: len 7; hex af000000310134; asc 1 4;;
3: len 10; hex 66726573642020202020; asc fresd ;;
Record lock, heap no 6 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
0: len 4; hex 80000005; asc ;;
1: len 6; hex 00000002c710; asc ;;
2: len 7; hex af000000310140; asc 1 @;;
3: len 10; hex 66736661202020202020; asc fsfa ;;
TABLE LOCK table `testdb1`.`t_test_2` trx id 182551 lock mode IXFrom the above information, it can be clearly seen that t_test_1 has acquired the IS lock, and there are 5 Record lock information, that is, 5 records are locked, and this table has only 5 records, so the entire table is locked.
TABLE LOCK table testdb1.t_test_1 trx id 182551 lock mode IS
Lock the entire table solution
insert into t_test_2 select * from t_test_1 where name like'trest'; In this sql statement, the name field of the t_test_1 table has no index, and the index has gone through a full table scan. If you create an index in the name field, what will happen Change it to
create an index
[root@localhost] 17:54:33 [testdb1]>alter table t_test_1 add index idx_t_test_1_name (name);
Query OK, 0 rows affected (0.24 sec)
Records: 0 Duplicates: 0 Warnings: 0
[root@localhost] 17:54:52 [testdb1]>begin;
Query OK, 0 rows affected (0.00 sec)
[root@localhost] 17:54:55 [testdb1]>insert into t_test_2 select * from t_test_1 where name like 'trest';
Query OK, 1 row affected (0.00 sec)
Records: 1 Duplicates: 0 Warnings: 0Re-obtain innodb lock details
TRANSACTIONS
------------
Trx id counter 182565
Purge done for trx's n:o < 182565 undo n:o < 0 state: running but idle
History list length 0
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 421524582451936, not started
0 lock struct(s), heap size 1136, 0 row lock(s)
---TRANSACTION 182560, ACTIVE 3 sec
3 lock struct(s), heap size 1136, 2 row lock(s), undo log entries 1
MySQL thread id 11, OS thread handle 140049254979328, query id 105 localhost root
TABLE LOCK table `testdb1`.`t_test_1` trx id 182560 lock mode IS
RECORD LOCKS space id 97 page no 4 n bits 72 index idx_t_test_1_name of table `testdb1`.`t_test_1` trx id 182560 lock mode S
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
0: len 8; hex 73757072656d756d; asc supremum;;
Record lock, heap no 6 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
0: len 10; hex 74726573742020202020; asc trest ;;
1: len 4; hex 80000001; asc ;;
TABLE LOCK table `testdb1`.`t_test_2` trx id 182560 lock mode IX
Do you see it? Here, there is only one Record lock, not the entire table.
The analysis of this failure is incomplete, to be continued.