查询超时功能

需求

一个查询耗时过长时，最好能够自动中断，避免阻塞客户端。

功能设计

Kill 查询接口

计划提供两个接口：

• 查看当前正在执行的查询，参考 Mysql sql 设计为 show query processlist，其结果集如下：

  QueryId	StartTime	SQL
  2	2020-12-01T14:37:00	select * from root.sg.device1;

  对于 SQL 过长（超过64字符）的情况，我们选择展示前面32个字符，以及后面32个字符，例如

  select device1.temperature, device1.speed, device2.status from root.storageGroup1 where time > 2020-12-01T00:00:00 and time < 2020-12-01T23:59:59

  QueryId	StartTime	SQL
  3	2020-12-01T14:47:00	select device1.temperature, devi ... 0 and time < 2020-12-01T23:59:59;

• 根据 queryId 取消对应查询，sql 设计为 kill query N，其中 N 为 queryId

查询取消的实现逻辑如下：

记录每个查询的执行线程，如果查询被取消，则将线程中断状态设为 true。同时在 SeriesReader 中设置检查点，如果检测到当前线程中断状态为 true，则抛出一个运行时错误，在 TSServiceImpl 中捕获这个错误，并向客户端返回查询取消的错误信息（可能是手动取消或查询超时）。

对于多线程异步执行的原始数据查询，在消费者线程，即主线程每次从阻塞队列中取数据前检查主线程是否被中断，如果被中断则抛出运行时错误，并在 TSServiceImpl 中捕获。消费者线程如果通过了取数据前的检查，而查询刚好在取数据过程中被中断，则此时消费者线程无法被成功中断。因此，在每个查询子线程执行查询前检测主线程的状态，如果主线程的中断状态为 true，则直接返回一个 ExceptionBatchdata，不再进行查询。在消费者主线程从阻塞队列中取数据时，检测到该错误数据，即可将 Exception 向上抛出，从而在 TSServiceImpl 中捕获。

超时参数

首先提供一个全局变量，作为默认的超时时间，如果用户没有未当前查询设定超时时间，则以全局时间为准。

在 JDBC 和 Session 支持在参数中为当前查询设定 timeout 参数，有手动设定超时时间的查询则以该私有时间为主。

监控线程

为了判断查询是否超时，在每个查询开始时，为该查询注册一个 timeout 时间后的定时任务。如果 timeout 时间后，queryId 仍然存在，则调用取消查询接口将查询 kill。

讨论

1. 查询多长时间默认设为超时合适？（用户可调）