解决方案(类似于linux服务器杀进程)：

// 1.查看最近所有sql进程
show full processlist;

// 2.kill 会话号;
kill 1373457;

周五的时候遇到一个特别操蛋的问题。

数据库(mysql) 部分SQL查询较慢，所以需要考虑优化的一些方面。

但由于本人粗心操作(新手上路)，在测试环境 使用 navicat 设计修改表结构的时候设置联合主键：原先的主键还是id，在原先基础上对另一个经常查询的字段添加索引，但是实际操作的确是原先的单主键更改为联合主键(两个)。在数千条数据的测试环境操作几秒钟完事，而且查询速度确是有上升。

 

于是非常的直接上正式环境操作，但是忽略了两个非常重要的问题：

1.时间是周五，(我们)产品的业务高峰时间段；

2.正式环境表数据过百万。

结果点击执行之后sql一时半会跑不完，再另跑一个查询此表的普通sql发现sql进程一直在running，而且没找到相关取消操作，再到正式环境查看软件发现以无法对外提供服务(涉及到我更改的这个表的所有请求全部timeout)

 

等了10分钟发现关联还没有添加完，心里着实很慌.....

 

请教大佬-技术负责人：

解决方案：

1. 查看sql进程列表 执行 以下sql命令

// 查看最近所有sql进程
show full processlist;

mysql 结束掉正在执行的sql mysql 终止查询_mysql 结束掉正在执行的sql

2. 干掉目前执行中的查询或更改进程

// kill 会话号;
kill 1373456;

有的时候进程可能不止一个，多查看几次，多杀几遍即可。

 

潜在安全问题：

1.涉及到复杂事务、多表关联的谨慎操作，有可能产生其他未知影响，具体待研究；

2.涉及到存储过程的操作，目前未接触；

3.其他。

因为本人当时操作属于单表更新，直接操作目前未受到较大影响！

 

反思：

从下午大约5：20开始执行sql，一直到40还没有解决问题，找大佬帮忙看并解决，最终5：52解决，全程耗时半个多小时，线上服务基本等同于宕机半小时。想起来就后怕。

幸而部分重要逻辑是通过消息队列异步执行的，半小时内的失败请求、操作基本后续可以自动恢复，截止到目前(第二天下午2：00)还没有收到线上崩溃或者问题反馈。