phpMyAdmin无法直接修复WordPress插件引发的死锁，需通过SHOW ENGINE INNODB STATUS定位LATEST DETECTED DEADLOCK确认死锁，无此段则多为长事务或锁等待；再用SHOW PROCESSLIST查State为Locked或Waiting for table metadata lock的进程ID，执行KILL终止；同时检查wp_options等表是否残留未提交事务或损坏，必要时OPTIMIZE TABLE修复。
phpmyadmin 本身不能直接修复 wordpress 插件引发的数据库死锁——它只是个查询界面，真正要做的，是定位并终止阻塞线程、清理残留事务、恢复表状态。
怎么看是不是死锁？关键看 SHOW ENGINE INNODB STATUS 输出
登录 phpMyAdmin，切换到 SQL 标签页，执行：
SHOW ENGINE INNODB STATUS\G
重点找 LATEST DETECTED DEADLOCK 段落。如果没有这一节，大概率不是死锁，而是长事务或锁等待（TRANSACTION 块里出现 waiting for lock 或 lock struct(s) 多行）。WordPress 插件常因未提交事务、异常退出导致锁残留，而非严格意义上的死锁。
- 若看到
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:和*** (2) HOLDS THE LOCK(S):—— 这是典型锁等待，需手动 kill - 若
SHOW PROCESSLIST里大量Locked或Waiting for table metadata lock状态，大概率是插件执行 DDL（如 ALTER TABLE）卡住 - 注意时间戳：如果
TRANSACTION的trx_started是几小时前，基本可判定为悬挂事务
怎么杀掉卡住的线程？用 KILL + PROCESSLIST
先查活跃连接：
SHOW PROCESSLIST;
重点关注 State 列为 Locked、Waiting for table metadata lock 或长时间 Updating/Writing to net 的行，记下它们的 ID（第一列）。再逐个终止：
立即学习“PHP免费学习笔记（深入）”；
KILL 12345;
注意：
使用tbot机器ID身份文件配合tsh CLI，通过Teleport访问控制SSH登录托管主机或执行远程命令。
- 不要 kill
system user或unauthenticated user类型的 ID - WordPress 后台请求通常对应
User为wordpress或你数据库用户名，优先 kill 这些 - 若
KILL后状态仍不更新，可能是内核级锁（如正在写 binlog），需等几秒再查；反复失败说明底层 I/O 或磁盘满 - 某些托管环境（如 cPanel 共享主机）会禁用
KILL权限，此时只能联系支持重启 MySQL
插件改表卡住怎么办？检查并修复 wp_options 和插件专用表
很多插件（尤其是缓存、SEO、备份类）会在激活/更新时对 wp_options 或自建表执行 ALTER TABLE ... ADD COLUMN，一旦中断就留个 metadata lock，整个表无法读写。确认方式：
- 执行
SELECT * FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(TIMEDIFF(NOW(), trx_started)) > 60;找超 1 分钟的事务 - 查
information_schema.PROCESSLIST中Info字段含ALTER、CREATE INDEX的记录 - 临时禁用插件：在 phpMyAdmin 中直接编辑
wp_options表，把option_name=active_plugins的option_value清空（或改为a:0:{}），再删掉疑似问题插件的文件夹
若表已损坏（如 wp_options 出现 #1030 - Got error 134 from storage engine），运行修复：
REPAIR TABLE wp_options;
但注意：MyISAM 表才支持 REPAIR，InnoDB 需靠 OPTIMIZE TABLE 或重建表；WordPress 默认用 InnoDB，所以更推荐：
OPTIMIZE TABLE wp_options;
预防比修复重要：插件操作前必须关掉自动提交
WordPress 默认开启 autocommit，但插件开发者有时会显式关闭（SET autocommit = 0）后忘记 commit/rollback。你在 phpMyAdmin 执行任何 DML 前，先确认当前会话状态：
SELECT @@autocommit;
返回 0 就危险了——后续所有 UPDATE/INSERT 都会挂起锁直到 commit 或连接断开。安全做法：
- 在 phpMyAdmin SQL 窗口顶部勾选
Enable foreign key checks和Autocommit（确保开启） - 手动执行修改前加一句：
SET autocommit = 1; - 插件更新失败后，别急着重试，先
SHOW PROCESSLIST看有没有残留连接
真正的难点不在命令怎么敲，而在于区分「锁等待」和「死锁」、「事务未提交」和「MySQL 崩溃」——日志里一行 trx_state: RUNNING 和 trx_state: LOCK WAIT 的差别，决定了你是 kill 还是等。
