为什么我查询全表不报错，加上日期时间条件反而报ERROR 9002 (HY000): TiKV server timeout

🪐 TiDB 技术问题 性能调优
1

为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：

【TiDB 版本】
V4.0.7
【问题描述】
在查询sql 时，全表扫描可以查询完成，但是加上日期条件以后就报超时ERROR 9002 (HY000): TiKV server timeout，
sql如下，
mysql> select branch_code, count(1) ct from (
-> select t.waybill_no,
-> t.branch_code
-> from (select waybill_no,branch_code from t_wide_order4 where branch_code=‘xxxxxxx’ and order_create_time >= date(‘2021-03-20’) and order_create_time < date(‘2021-03-21’)) t
-> left join (select waybill_no from test_all_operation4) w
-> on t.waybill_no = w.waybill_no
-> ) tab
-> group by branch_code
-> order by branch_code;
ERROR 9002 (HY000): TiKV server timeout

mysql> select branch_code, count(1) ct from (
-> select t.waybill_no,
-> t.branch_code
-> from (select waybill_no,branch_code from t_wide_order4 where branch_code=‘xxxxxxx’) t
-> left join (select waybill_no from test_all_operation4) w
-> on t.waybill_no = w.waybill_no
-> ) tab
-> group by branch_code
-> order by branch_code;
成功返回。

表结构如下
CREATE TABLE t_wide_order4 (
waybill_no varchar(100) NOT NULL COMMENT ‘单号’,
order_channel_code varchar(100) DEFAULT NULL,
order_create_time timestamp NOT NULL,
order_logistics_code varchar(100) DEFAULT NULL,
order_status varchar(100) DEFAULT NULL,
dispersion_order_flag varchar(100) DEFAULT NULL,
order_insert_time timestamp NULL DEFAULT NULL,
sender_prov_code varchar(100) DEFAULT NULL,
sender_city_code varchar(100) DEFAULT NULL,
sender_county_code varchar(100) DEFAULT NULL,
recipient_prov_code varchar(100) DEFAULT NULL,
recipient_city_code varchar(100) DEFAULT NULL,
recipient_county_code varchar(100) DEFAULT NULL,
curtime varchar(100) DEFAULT NULL,
branch_code varchar(100) DEFAULT NULL,
seller_id varchar(100) DEFAULT NULL,
seller_name varchar(100) DEFAULT NULL,
customer_code varchar(100) DEFAULT NULL,
company_code varchar(100) DEFAULT NULL,
action_type varchar(100) DEFAULT NULL,
is_aliorder varchar(100) DEFAULT NULL,
datoubi varchar(100) DEFAULT NULL,
order_chanel varchar(100) DEFAULT NULL,
yzd_flag varchar(100) DEFAULT NULL,
PRIMARY KEY (waybill_no,order_create_time),
KEY idx_t_wide_order_01 (waybill_no)
)

若提问为性能优化、故障排查类问题，请下载脚本运行。终端输出的打印结果，请务必全选并复制粘贴上传。

2

image
image1380×136 24.5 KB

  1. 检查下 tikv 日志的报错信息，是否某个节点异常
  2. 可以查看监控信息， grafana 的 over-view 查看负载是否有高的机器
  3. 查看 tikv 监控，是否有资源有瓶颈，比如 raft store cpu 打满等。
3

select branch_code, count(1) ct from (
select t.waybill_no,
t.branch_code
from (select waybill_no,branch_code from t_wide_order4 partition(p20210321) where branch_code=‘210899’) t
left join (select waybill_no from test_all_operation4) w
on t.waybill_no = w.waybill_no
) tab
group by branch_code
order by branch_code; 用这种方式就可以了t_wide_order4 partition(p20210321) 。正常查询。就是分区键引起的问题。
但是查询2个sql语句的执行计划都是一样的。

image
image1920×1080 301 KB

这个是执行异常SQL时的over-view监控图。。。这个资源一下就上去了。这个是什么原理。

t_wide_order4 partition(p20210321) 这种分区方式查询正常。
order_create_time >= date(‘2021-03-20’) and order_create_time < date(‘2021-03-21’) 不正常。
分区键也正常
image

4

image
image1342×336 14.7 KB

这两种方式查询的数据量也是一样的。但是用在SQL里t_wide_order4 partition(p20210321)这种方式基本不耗费资源，但是用order_create_time >= date(‘2021-03-20’) and order_create_time < date(‘2021-03-21’)这种方式就非常耗费资源并且超时查不出来

5

两个 SQL 对应的 explain 的结果可以发下看么

6

explain-sql.txt (9.8 KB)

7

unix_timestamp 在分区裁剪方面的确是有一些问题，预计会在 5.0 中带上，可以考虑等 5.0.0 版本出来再测试一下。目前先通过指定分区的方式，手动进行分区裁剪。