MySQL 5.7上的元數據鎖定，無法找到鎖定過程？

Question

所以我有一個python服務器與MySQL數據庫（當前睡眠）連接。我去phpMyAdmin，只是試圖截斷「工具」表，這是「組織」數據庫的一部分。但它不起作用。問題是，我似乎無法找到哪個查詢實際上鎖定它。

mysql> show full processlist; 
+-----+------+-----------+----------+---------+------+---------------------------------+------------------------+ 
| Id | User | Host  | db  | Command | Time | State       | Info     | 
+-----+------+-----------+----------+---------+------+---------------------------------+------------------------+ 
| 175 | user | localhost | organize | Sleep | 1235 |         | NULL     | 
| 244 | user | localhost | NULL  | Query | 0 | starting      | show full processlist | 
| 307 | user | localhost | organize | Query | 272 | Waiting for table metadata lock | TRUNCATE TABLE `tools` | 
| 308 | user | localhost | NULL  | Sleep | 272 |         | NULL     | 
+-----+------+-----------+----------+---------+------+---------------------------------+------------------------+ 
4 rows in set (0.00 sec) 

mysql> 

雖然SHOW ENGINE INNODB STATUS給出如下：

mysql> SHOW ENGINE INNODB STATUS; 
---------------------------------------------------------------------------+ 
| InnoDB |  | 
===================================== 
2017-03-16 14:18:08 0x7fa0da508700 INNODB MONITOR OUTPUT 
===================================== 
Per second averages calculated from the last 6 seconds 
----------------- 
BACKGROUND THREAD 
----------------- 
srv_master_thread loops: 46 srv_active, 0 srv_shutdown, 4115 srv_idle 
srv_master_thread log flush and writes: 4161 
---------- 
SEMAPHORES 
---------- 
OS WAIT ARRAY INFO: reservation count 2 
OS WAIT ARRAY INFO: signal count 2 
RW-shared spins 0, rounds 4, OS waits 2 
RW-excl spins 0, rounds 0, OS waits 0 
RW-sx spins 0, rounds 0, OS waits 0 
Spin rounds per wait: 4.00 RW-shared, 0.00 RW-excl, 0.00 RW-sx 
------------ 
TRANSACTIONS 
------------ 
Trx id counter 5384 
Purge done for trx's n:o < 0 undo n:o < 0 state: running but idle 
History list length 0 
LIST OF TRANSACTIONS FOR EACH SESSION: 
---TRANSACTION 421804127426384, not started 
0 lock struct(s), heap size 1136, 0 row lock(s) 
-------- 
FILE I/O 
-------- 
I/O thread 0 state: waiting for completed aio requests (insert buffer thread) 
I/O thread 1 state: waiting for completed aio requests (log thread) 
I/O thread 2 state: waiting for completed aio requests (read thread) 
I/O thread 3 state: waiting for completed aio requests (read thread) 
I/O thread 4 state: waiting for completed aio requests (read thread) 
I/O thread 5 state: waiting for completed aio requests (read thread) 
I/O thread 6 state: waiting for completed aio requests (write thread) 
I/O thread 7 state: waiting for completed aio requests (write thread) 
I/O thread 8 state: waiting for completed aio requests (write thread) 
I/O thread 9 state: waiting for completed aio requests (write thread) 
Pending normal aio reads: [0, 0, 0, 0] , aio writes: [0, 0, 0, 0] , 
ibuf aio reads:, log i/o's:, sync i/o's: 
Pending flushes (fsync) log: 0; buffer pool: 0 
229 OS file reads, 390 OS file writes, 13 OS fsyncs 
0.00 reads/s, 0 avg bytes/read, 0.00 writes/s, 0.00 fsyncs/s 
------------------------------------- 
INSERT BUFFER AND ADAPTIVE HASH INDEX 
------------------------------------- 
Ibuf: size 1, free list len 0, seg size 2, 0 merges 
merged operations: 
insert 0, delete mark 0, delete 0 
discarded operations: 
insert 0, delete mark 0, delete 0 
Hash table size 69257, node heap has 0 buffer(s) 
Hash table size 69257, node heap has 0 buffer(s) 
Hash table size 69257, node heap has 0 buffer(s) 
Hash table size 69257, node heap has 0 buffer(s) 
Hash table size 69257, node heap has 0 buffer(s) 
Hash table size 69257, node heap has 0 buffer(s) 
Hash table size 69257, node heap has 0 buffer(s) 
Hash table size 69257, node heap has 0 buffer(s) 
0.00 hash searches/s, 0.00 non-hash searches/s 
--- 
LOG 
--- 
Log sequence number 2232766 
Log flushed up to 2232766 
Pages flushed up to 2232766 
Last checkpoint at 2232757 
0 pending log flushes, 0 pending chkp writes 
10 log i/o's done, 0.00 log i/o's/second 
---------------------- 
BUFFER POOL AND MEMORY 
---------------------- 
Total large memory allocated 274857984 
Dictionary memory allocated 317906 
Buffer pool size 16384 
Free buffers  16129 
Database pages  255 
Old database pages 0 
Modified db pages 0 
Pending reads  0 
Pending writes: LRU 0, flush list 0, single page 0 
Pages made young 0, not young 0 
0.00 youngs/s, 0.00 non-youngs/s 
Pages read 203, created 52, written 370 
0.00 reads/s, 0.00 creates/s, 0.00 writes/s 
No buffer pool page gets since the last printout 
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s 
LRU len: 255, unzip_LRU len: 0 
I/O sum[0]:cur[0], unzip sum[0]:cur[0] 
-------------- 
ROW OPERATIONS 
-------------- 
0 queries inside InnoDB, 0 queries in queue 
0 read views open inside InnoDB 
Process ID=25594, Main thread ID=140328678156032, state: sleeping 
Number of rows inserted 2782, updated 0, deleted 0, read 2792 
0.00 inserts/s, 0.00 updates/s, 0.00 deletes/s, 0.00 reads/s 
---------------------------- 
END OF INNODB MONITOR OUTPUT 
============================ 

而綜觀performance_schema.meta_locks給出了這樣的：

mysql> select * from metadata_locks; 
+-------------+--------------------+------------------+-----------------------+---------------------+---------------+-------------+-------------------+-----------------+----------------+ 
| OBJECT_TYPE | OBJECT_SCHEMA  | OBJECT_NAME  | OBJECT_INSTANCE_BEGIN | LOCK_TYPE   | LOCK_DURATION | LOCK_STATUS | SOURCE   | OWNER_THREAD_ID | OWNER_EVENT_ID | 
+-------------+--------------------+------------------+-----------------------+---------------------+---------------+-------------+-------------------+-----------------+----------------+ 
| TABLE  | organize   | AccessMatrixView |    72627408 | SHARED_READ   | TRANSACTION | GRANTED  | sql_parse.cc:6030 |    334 |    4 | 
| TABLE  | organize   | access_matrix |    80700416 | SHARED_READ   | TRANSACTION | GRANTED  | sql_parse.cc:6030 |    334 |    4 | 
| TABLE  | organize   | people   |    81091984 | SHARED_READ   | TRANSACTION | GRANTED  | sql_parse.cc:6030 |    334 |    4 | 
| TABLE  | organize   | tools   |    79476128 | SHARED_READ   | TRANSACTION | GRANTED  | sql_parse.cc:6030 |    334 |    7 | 
| GLOBAL  | NULL    | NULL    |  140327657064288 | INTENTION_EXCLUSIVE | STATEMENT  | GRANTED  | sql_base.cc:5496 |    335 |   170 | 
| SCHEMA  | organize   | NULL    |  140327657360976 | INTENTION_EXCLUSIVE | TRANSACTION | GRANTED  | sql_base.cc:5481 |    335 |   170 | 
| TABLE  | organize   | tools   |  140327657150944 | EXCLUSIVE   | TRANSACTION | PENDING  | sql_parse.cc:6030 |    335 |   170 | 
| TABLE  | performance_schema | metadata_locks |  140327923115360 | SHARED_READ   | TRANSACTION | GRANTED  | sql_parse.cc:6030 |    351 |    94 | 
+-------------+--------------------+------------------+-----------------------+---------------------+---------------+-------------+-------------------+-----------------+----------------+ 
8 rows in set (0.00 sec) 

mysql> 

任何人都可以在這裏幫我診斷的問題？

Answer 1

它的線程335

mysql> select * from metadata_locks; 
+-------------+--------------------+------------------+-----------------------+---------------------+---------------+-------------+-------------------+-----------------+----------------+ 
| OBJECT_TYPE | OBJECT_SCHEMA  | OBJECT_NAME  | OBJECT_INSTANCE_BEGIN | LOCK_TYPE   | LOCK_DURATION | LOCK_STATUS | SOURCE   | OWNER_THREAD_ID | OWNER_EVENT_ID | 
+-------------+--------------------+------------------+-----------------------+---------------------+---------------+-------------+-------------------+-----------------+----------------+ 
| GLOBAL  | NULL    | NULL    |  140327657064288 | INTENTION_EXCLUSIVE | STATEMENT  | GRANTED  | sql_base.cc:5496 |    335 |   170 | 
| SCHEMA  | organize   | NULL    |  140327657360976 | INTENTION_EXCLUSIVE | TRANSACTION | GRANTED  | sql_base.cc:5481 |    335 |   170 | 
| TABLE  | organize   | tools   |  140327657150944 | EXCLUSIVE   | TRANSACTION | PENDING  | sql_parse.cc:6030 |    335 |   170 | 
+-------------+--------------------+------------------+-----------------------+---------------------+---------------+-------------+-------------------+-----------------+----------------+ 
>>>>>> here >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> ^^^ 

上organize.tools鎖本身似乎實際上是在等待同一個線程持有的另外兩個鎖。任何其他需要衝突的鎖都會在這些之後等待。

在SHOW PROCESSLIST中看不到此線程，因爲您登錄的用戶沒有PROCESS權限，允許您查看其他用戶擁有的線程以及他們正在執行的操作。

PROCESS特權涉及顯示關於在服務器內執行的線程的信息（即關於正在由會話執行的語句的信息）。該特權使得能夠使用SHOW PROCESSLIST或mysqladmin processlist來查看屬於其他賬戶的線索;你總能看到你自己的線程

https://dev.mysql.com/doc/refman/5.7/en/privileges-provided.html#priv_process

注意mysqladmin processlist（在帖中提到的）是不是你運行一個查詢 - 這是一個shell命令，可以讓你看到在響應中提供的信息相同查詢SHOW PROCESSLIST。

Answer 2

因此，要擴展其他答案，這是我計算出的日子TRUNCATE不等於DELETE FROM table。傻我。

每documentation：

從邏輯上講，truncate table要類似於刪除所有行，或DROP TABLE序列DELETE語句和CREATE TABLE語句。爲了實現高性能，它繞過了刪除數據的DML方法。因此，它不能被回滾，它不會導致ON DELETE觸發器觸發，並且無法對具有父子外鍵關係的InnoDB表執行。

雖然truncate table要類似於DELETE，它被列爲DDL語句而不是DML statement.`

從本質上講，這個過程在SLEEP狀態下讀取表，但TRUNCATE試圖做一個DDL語句，因此它被阻塞，直到其他SLEEP -ing進程被終止。