记一次数据库查询超时优化问题

2 上网搜索了下 KILL QUERY 发生的场景，在一篇文章 深入分析JDBC超时机制 找到问题所在，sql 执行超时，jdbc 会向 mysql 服务发送一个kill 命令，从而让 mysql 停止 sql 执行。不过传给了 mycat 服务，mycat 没有处理该命令，而是直接报错返回

3 查看了下应用服务的配置，在 jdbc:url 统一配置的 mysql socket 执行超时时间是 15s。而在 mybatis 单独的 sql 执行语句配置的设置更长，是 20s（注意这里的配置是 xml 加 注解的方式）

3.1 mybatis xml里的 sql 语句我单独在客户端执行，测试的 sql 执行时间大概在 6，7 秒左右，是不会超过 15s 这个限制的，但是从定时任务调度日志看，每次任务总体上就执行了 8 秒左右，说明 mycat 确实是在15秒内收到超时 KILL 命令，从而导致sql 执行失败

4 想着是不是在其他地方配置超时。细看了下 mybatis 的配置，还真有一个统一 sql 超时配置，default-statement-timeout = 5 -

从mybatis 源码文档上看，单独设置的 mybatis @Options timeout属性是会覆盖掉在 yml 配置的 default-statement-timeout属性的。难道是 @Options 没生效 ？

5 因此决定本地调试一波。发现 @Options 还真的没生效，jdbc的 queryTimeout 取值的是 mybatis在yml的 全局配置