普通用户可通过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 请求生命周期短的场景下，比修连接池逻辑成本更低
