普通用户可通过SHOW PROCESSLIST查自身连接并用KILL ID终止卡死进程，需确认线程ID来自自己会话；推荐优先配置应用层超时与连接池清理而非手动KILL。

普通用户怎么查到并 kill 自己触发的死锁进程

普通用户无法直接 kill 其他用户的线程，但能安全终止自己发起的、卡在死锁中的连接——前提是知道自己的 connection_id()，且没被管理员显式禁用 process 权限（该权限默认对所有用户开放）。

常见错误现象：执行一条 UPDATE 卡住不动，SHOW PROCESSLIST 里看到状态是 updating 或 Locked，但没报错；其实它已被 InnoDB 回滚，只是客户端没收到响应，连接还挂着。

• 先确认是不是真死锁：执行 SHOW ENGINE INNODB STATUS\G，重点看 LATEST DETECTED DEADLOCK 段，里面会写明哪个事务被选为 victim、哪个线程 ID（trx_mysql_thread_id）被回滚了
• 查自己当前所有连接：SELECT ID, USER, HOST, DB, COMMAND, TIME, STATE, INFO FROM INFORMATION_SCHEMA.PROCESSLIST WHERE USER = CURRENT_USER();
• 如果发现某条 INFO 是你刚发的 SQL，且 STATE 长时间停在 updating 或 Waiting for table metadata lock，基本就是卡死了，不是被 kill 就是自己卡着没释放
• KILL 只接受线程 ID（即 ID 列），不是事务 ID：KILL 12345; —— 这个 12345 必须来自你自己的 PROCESSLIST 结果

为什么不能用 SUPER 权限替代？它根本不是“替代方案”

SUPER 权限是高危全局权限，允许 KILL 任意线程、修改全局变量、启动/停止复制等。给普通用户开 SUPER 不是“替代”，是拿消防斧切菜——既没必要，又容易误伤。

使用场景非常有限：运维批量处理、DBA 故障介入。日常开发、测试、甚至大部分运维脚本都不需要它。

• MySQL 8.0+ 默认关闭 SUPER，改用细粒度权限（如 SYSTEM_VARIABLES_ADMIN、CONNECTION_ADMIN），KILL 对应的是 CONNECTION_ADMIN，但它仍不允许 kill 别人
• 即使你有 SUPER，kill 错了活跃的主从线程或系统线程（如 event_scheduler），可能直接导致复制中断或定时任务失效
• 很多云数据库（如阿里云 RDS、腾讯云 CDB）直接屏蔽 SUPER，也不允许自定义权限，此时硬加 SUPER 根本不可行

真正可行的低权限方案：用 application-level timeout + connection cleanup

与其纠结“怎么 kill”，不如让连接自己按时退出。数据库层的 wait_timeout 和应用层的 query timeout 双重兜底，比手动 KILL 更可靠、更可控。

性能影响几乎为零，兼容性覆盖所有 MySQL 版本和主流驱动（Python mysql-connector、Java JDBC、Node.js mysql2）。

• 设置会话级超时：SET SESSION innodb_lock_wait_timeout = 10;（单位秒，注意这不解决死锁，只缩短等待时间）
• 应用代码里必须设 query timeout：比如 JDBC 的 statement.setQueryTimeout(10)，mysql2 的 timeout: 10000 选项
• 连接池要配 maxLifetime 和 idleTimeout，避免陈旧连接堆积——死锁残留连接常表现为 Sleep 状态但 TIME 超过 1 小时
• 别依赖 autocommit=1 来“防死锁”：显式事务中单条语句失败，事务仍处于打开状态，连接不会自动释放

最容易被忽略的点：kill 之后连接未必断开，客户端可能还在等响应

执行 KILL 后，MySQL 确实会终止线程，但 TCP 连接是否立即关闭，取决于客户端行为和网络栈。很多 ORM（如 Django、SQLAlchemy）默认不检测连接异常，下次复用这个连接时才报 Lost connection during query。

这意味着：你以为 kill 完就干净了，其实应用里那个 connection 对象还活着，下一次 query 会失败，甚至引发雪崩。

• Go 的 database/sql 会在 Exec/Query 失败后自动标记连接为 bad，下次从 pool 取时丢弃
• Python 的 pymysql 需手动捕获 OperationalError 并调用 connection.close()，否则连接一直留在 pool 里
• 最稳妥做法：kill 后，强制让应用重建连接，而不是复用——尤其在 Web 请求生命周期短的场景下，比修连接池逻辑成本更低