MySQL进程停留在“清理”上，永远锁定表

Question

有人建议我在这里发表文章，而不是StackOverflow。我刚开始调试mysql/innodb问题，所以这里是我所拥有的最好的：

我试图运行一个集成测试，因此每次测试结果几乎相同，测试始终挂在同一个位置，同时试图执行相同的更新。我得到了一个冲突的进程，它锁定了更新试图使用的表。如果我只让它运行，就会得到一个超过异常的锁定超时，当我终止麻烦的进程时，事情就会再次开始移动，尽管在我的测试中抛出了一个异常--“org.mariadb.jdbc.internal.util.dao.QueryException:无法发送查询:最后一次流未完成”。

我能找到的相关信息，

SHOW ENGINE INNODB STATUS;

------------
TRANSACTIONS
------------

---TRANSACTION 2609485, ACTIVE 36 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 9 lock struct(s), heap size 1136, 4 row lock(s), undo log entries 2
MySQL thread id 231, OS thread handle 162200, query id 10577 localhost 127.0.0.1 root updating
/* update com.ipl.inspire.imp.radio.entities.entity.circuit.Circuit */ 
update abstract_asset_network
    set lastUpdated='2016-01-14 15:34:10.2', leg=0, networkStatus_id=4,
        parent_id=NULL, xCoordinate=0, yCoordinate=0 where id=33
Trx read view will not see trx with id >= 2609485, sees < 2609468
------- TRX HAS BEEN WAITING 35 SEC FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 89945 page no 3 n bits 72 index PRIMARY
  of table `imptest`.`abstract_asset_network` trx id 2609485
  lock_mode X locks rec but not gap waiting
Record lock, heap no 3 PHYSICAL RECORD: n_fields 9; compact format; info bits 0
 0: len 4; hex 80000021; asc    !;;
 1: len 6; hex 00000027d0f8; asc    '  ;;
 2: len 7; hex 6e0000019b2827; asc n    (';;
 3: len 7; hex 99985cf88a07d0; asc   \    ;;
 4: len 1; hex 00; asc  ;;
 5: len 4; hex 80000000; asc     ;;
 6: len 4; hex 80000000; asc     ;;
 7: len 4; hex 80000003; asc     ;;
 8: SQL NULL;

------------------
---TRANSACTION 2609468, ACTIVE 38 sec
10 lock struct(s), heap size 1136, 4 row lock(s), undo log entries 3
MySQL thread id 228, OS thread handle 162260, query id 10138 localhost 127.0.0.1 root cleaning up
Trx read view will not see trx with id >= 2609468, sees < 2609468

这里有两个事务，而trx 2609468似乎导致查询更新在2秒后执行(trx 2609485)的锁。锁似乎永远存在(或者直到innodb_lock_wait_timeout被击中，我已经尝试增加了)。

SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX

trx_id  trx_state   trx_started         trx_requested_lock_id  trx_wait_started     trx_weight  trx_mysql_thread_id   trx_query                                                                                                                                                                                                                         trx_operation_state    trx_tables_in_use    trx_tables_locked   trx_lock_structs   trx_locks_memory_bytes    trx_rows_locked   trx_rows_modified   trx_concurrency_tickets    trx_isolation_level
2609485 LOCK WAIT   2016-01-14 15:34:17 2609485:89945:3:3      2016-01-14 15:34:18  11          231                   update abstract_asset_network set lastUpdated='2016-01-14 15:34:10.2', leg=0, networkStatus_id=4, parent_id=NULL, xCoordinate=0, yCoordinate=0 where id=33                                                                        starting index read    1                    5                   9                  1136                      4                 2                   0                          REPEATABLE READ
2609468 RUNNING     2016-01-14 15:34:15                                             13          228                                                                                                                                                                                                                                                                            0                    6                   10                 1136                      4                 3                   0                          REPEATABLE READ

这在很大程度上暗示了我所相信的innodb状态查询所解释的内容，尽管也许其他人可以理解它。

在进程id 228上执行的最后一个查询是(来自general_log)

228 Query   /* select generatedAlias0 from Imp as generatedAlias0 */
select imp0_.id as id1_67_, imp0_.black as black2_67_, imp0_.current as current3_67_,
       imp0_.name as name4_67_, imp0_.redMessageHost as redMessa5_67_,
       imp0_.redMessagePort as redMessa6_67_, imp0_.site_id as site_id7_67_
    from imp imp0_

然后以后：

231 Query   update abstract_asset_network
     set lastUpdated='2016-01-14 15:34:10.2', leg=0, networkStatus_id=4,
         parent_id=NULL, xCoordinate=0, yCoordinate=0 where id=33
.
.
.
8 Query kill 228
231 Query   COMMIT
231 Query   set autocommit=1
231 Query   SELECT 1
231 Query   set autocommit=0
231 Query   /* select ...

但我不认为这是相关的，这更多的是因为这个过程被重新用于“清理”其他事情。但是，这个具有相同进程/定时/锁/查询的场景每次都发生相同的情况，唯一的变化就是ids。

Answer 1

你的MySQL版本是什么？我认为这可能是MySQL的错误。MySQL错误清理

它在5.6.17版本的MySQL 5.6.17发行说明中被修正了

InnoDB:显示引擎INNODB状态输出显示>空闲线程的“清理”状态。执行语句后没有重置线程状态信息。(Bug #21974225，Bug #78777)

希望它能帮到你。