所以我有一个python服务器与MySQL数据库（当前睡着了）的连接。我转到phpMyAdmin并尝试截断“tools”表，它是“组织”数据库的一部分。但它不起作用。问题是，我似乎无法找到实际锁定它的查询。
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>
有人可以帮我诊断这个问题吗？
答案 0 :(得分：0)
这是主题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 >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> ^^^
organiz.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时提供的相同信息。
答案 1 :(得分：0)
所以为了扩展另一个答案，这是我发现TRUNCATE不等同于DELETE FROM table的那一天。傻我。
逻辑上，TRUNCATE TABLE类似于删除所有行的DELETE语句，或者删除DROP TABLE和CREATE TABLE语句的序列。为了实现高性能，它绕过了删除数据的DML方法。因此，它不能回滚，它不会导致触发ON DELETE触发器，并且不能对具有父子外键关系的InnoDB表执行它。
虽然TRUNCATE TABLE与DELETE类似，但它被归类为DDL语句而不是DML语句。
基本上，SLEEP状态的进程正在读取表，但TRUNCATE正在尝试执行DDL语句，因此它被阻塞直到另一个SLEEP进程被杀了。
答案 2 :(得分：0)
我遇到了同样的问题，我正在执行：ALTER TABLE Version MODIFY COLUMN version VARCHAR（15）;
Version是只有1行的表，没有外键，是存储我当前代码版本的非常简单的表。
我花了多个小时修改上一个命令，但问题出在最后一个SQL指令
我正在用mysql在python中询问：
cur = execute（“ SELECT * FROM Version”）
然后，如果我的版本是旧的
execute（更改表
Version修改列versionVARCHAR（15）;） 提交
似乎SELECT锁定了表，它在等待我释放，因此我必须在执行后添加提交。这是我在咨询后第一次添加提交，我只是在提交用于修改数据库的指令。
所以对我来说，解决方案是在被锁定的指令之前提交最后一条SQL指令。