1. 出现长时间执行的查询的原因
2. 长时间执行的查询带来的问题
3. 如何避免长时间执行的查询
4. 如何处理长时间执行的查询
4.1 DMS 处理会话
4.2 设置查询最长执行时间
4.3 创建事件自动清理长时间执行的查询
1. 出现长时间执行的查询的原因
在使用 MySQL 的过程中，由于某些原因，比如被 SQL 注入、SQL执行效率较差、DDL 语句引起表元数据锁等待等等，会出现运行时间很长的查询。
由于被SQL注入而导致的长时间查询：
由于DDL语句引起表元数据锁等待:
2. 长时间执行的查询带来的问题
通常来说，除非是BI/报表类查询，否则长时间执行的查询对于应用缺乏意义。
消耗系统资源，比如大量长时间查询可能会引起 CPU、IOPS 和/或 连接数 使用率过高等问题。
带来系统不稳定的隐患(比如 InnoDB 引擎表上的长时间查询可能会导致 ibdata1 系统文件尺寸的增加)。
3. 如何避免长时间执行的查询
应用方面应注意增加防止 SQL 注入的保护。
在新功能模块上线前，进行压力测试，避免出现执行效率很差的 SQL 大量执行的情况。
尽量在业务低峰期进行索引创建删除、表结构修改、表维护和表删除操作。
4. 如何处理长时间执行的查询
4.1 DMS 清理会话
也可以通过命令 show processlist; 查看当前执行会话，清理长时间查询。
4.2 设置查询最长执行时间
可以通过设置 loose_max_statement_time 参数来限制查询的最长执行时间，该参数单位是 毫秒(MS)。
#
参数名称
默认值
最小值
最大值
作用
1
loose_max_statement_time
0
0
4294967295
限制SQL语句执行的最长时间，单位毫秒(ms)
比如：
注：
修改该参数设置，对修改设置前已经存在的会话不生效；对修改设置后新创建的会话有效。
loose_max_statement_time 限制 SQL 执行 时间；如果 DML 操作出现 InnoDB 行锁等待，锁等待时间是不计入执行时间的。
4.3 创建事件自动清理长时间执行的查询
创建 MySQL事件，自动清理长时间执行的查询。
比如下面的代码会每 5 分钟清理一次当前用户运行时间超过 1 个小时且非锁等待会话。
create event my_long_running_query_monitor
on schedule every 5 minute
starts '2015-09-15 11:00:00'
on completion preserve enable do
begin
declare v_sql varchar(500);
declare no_more_long_running_query integer default 0;
declare c_tid cursor for
select concat ('kill ',id,';') from
information_schema.processlist
where time >= 3600
and user = substring(current_user(),1,instr(current_user(),'@')-1)
and command not in ('sleep')
and state not like ('waiting for table%lock');
declare continue handler for not found
set no_more_long_running_query=1;
open c_tid;
repeat
fetch c_tid into v_sql;
set @v_sql=v_sql;
prepare stmt from @v_sql;
execute stmt;
deallocate prepare stmt;
until no_more_long_running_query end repeat;
close c_tid;
end;
注：样例仅供参考，请结合应用情况自行调整监控条件和运行间隔。