Navicat“停止”按钮发送的是KILL QUERY而非KILL，仅中断查询语句、保留连接，若线程处于Rolling back、Locked或Waiting for table metadata lock等状态，KILL QUERY会被挂起直至阶段完成；普通账号缺PROCESS权限时可能静默失败；v16及更早版本因同步模式导致UI冻结，无法真正中断，须升级至17.0.4+并启用异步查询。
Navicat“停止”按钮发送的是KILL QUERY，不是KILL
点击“停止”按钮后进程仍显示running，本质是因为它只向 mysql 发送 kill query 命令，而非 kill。前者仅中断当前查询语句，保留连接和事务上下文；后者会直接断开整个连接。若目标线程正处在 innodb 回滚、锁等待或系统级操作（如写 binlog、刷脏页）中，kill query 会被挂起，直到这些阶段完成——此时 show processlist 里 state 可能显示为 rolling back 或 waiting for table metadata lock，但 id 仍在。
State为Locked/Waiting时KILL QUERY大概率不立即生效
常见卡点状态及其行为差异：
-
Locked：通常因 MyISAM 表级锁或未提交事务持有行锁，KILL QUERY会等锁释放才退出，期间线程持续占用连接 -
Waiting for table metadata lock：说明有 ALTER TABLE、DROP TABLE 等 DDL 正在排队，或某长事务未结束，KILL QUERY无法绕过元数据锁机制 -
Updating或Writing to net：可能已执行完逻辑，正回传结果，此时KILL QUERY已生效，但 Navicat 还在等剩余网络包，UI 冻结至超时（默认 60 秒）
权限不足导致KILL QUERY被静默忽略
普通账号执行 KILL QUERY 需要 PROCESS 权限，但部分部署默认关闭该权限；若无 SUPER 或 CONNECTION_ADMIN，对其他用户线程的 KILL QUERY 会直接报错 Access denied，而 Navicat 不提示错误，仅让按钮“看起来点了但没反应”。
验证方式：新开查询窗口运行 SHOW GRANTS;，检查是否含 GRANT PROCESS ON *.*；若无，需 DBA 授权或改用有权限账号操作。
Navicat v16 及更早版本根本无法真正中断查询
v16 及之前版本使用同步 JDBC/ODBC 模式，UI 线程阻塞等待 recv() 返回完整结果集。即使服务端已响应 KILL QUERY，Navicat 仍卡在收包阶段，表现为光标旋转、菜单灰显、Ctrl+C 无效——这不是 MySQL 没响应，是客户端自己“瘫痪”了。
唯一解法是升级到 Navicat 17.0.4+ 并手动开启：Preferences → Query → Enable asynchronous query execution。注意该选项默认关闭，且需搭配 mysql-connector-j 8.0.33+ 驱动才生效。
Id 对应的线程，可能早已完成查询、正在回滚、或卡在操作系统层——这时候盯着 Navicat 界面刷新毫无意义，得去服务器上查 information_schema.innodb_trx 和 performance_schema.events_statements_current 才知道它到底卡在哪。
