topsql中高并发sql在各个kv之间转移问题

在topsql监控中观察到，有一段高并发的sql，昨天白天一直在147那个节点的kv中运行，到凌晨2点的时候突然转移到154那个节点的kv中去执行了一个小时，凌晨3点这个高并发的sql又跑到150节点去了，这个是什么原理？？

image1636×432 31.3 KB

image1576×434 25.7 KB

image1654×473 36.8 KB

各个节点都是没有重启的。

sql语句
SELECT
bi.id bikeid,
bi.vin,
sku.id skuid,
sku.color skucolor,
sku.img_url skuimageurl,
m.id modelid,
m.model_name modelname,
m.model_no modelno,
type.id typeid,
type.type_name typename,
type.type_code typecode,
series.id seriesid,
series.series_name seriesname,
series.series_code seriescode,
m.tire_diameter,
m.pole_pair
FROM
t_bike_info bi
LEFT JOIN t_bike_sku sku ON bi.sku_id = sku.id
LEFT JOIN t_bike_model m ON sku.model_id = m.id
LEFT JOIN t_bike_type TYPE ON m.type_id = type.id
LEFT JOIN t_bike_series series ON m.series_id = series.id
WHERE
bi.vin = ?
AND bi.del_flag = ?
AND sku.del_flag = ?
AND m.del_flag = ?
AND type.del_flag = ?
AND series.del_flag = ?
涉及的表结构 都加了 id bigint(19) NOT NULL /*T![auto_rand] AUTO_RANDOM(5) */ COMMENT ‘主键’,

你这个就是热点读

那他为什么会转移呢？

表结构

CREATE TABLE t_bike_info (
id bigint(19) NOT NULL /*T![auto_rand] AUTO_RANDOM(5) */ COMMENT ‘主键’,
sku_id bigint(19) NOT NULL DEFAULT ‘0’ ,
vin varchar(64) COLLATE utf8_general_ci NOT NULL DEFAULT ‘’ ,
vin_pwd varchar(64) COLLATE utf8_general_ci DEFAULT ‘’ ,
sap_vin varchar(64) COLLATE utf8_general_ci DEFAULT ‘-1’ ,
bind_code varchar(64) COLLATE utf8_general_ci DEFAULT NULL ,
frame_manu varchar(32) COLLATE utf8_general_ci DEFAULT NULL ,
sc_date timestamp(3) NULL DEFAULT NULL COMMENT ‘生产日期’,
fh_date timestamp(3) NULL DEFAULT NULL COMMENT ‘发货日期’,
dealer_no varchar(32) COLLATE utf8_general_ci DEFAULT NULL ,
djh varchar(200) COLLATE utf8_general_ci DEFAULT NULL ,
qc varchar(60) COLLATE utf8_general_ci DEFAULT NULL ,
iot_id bigint(19) DEFAULT NULL ,
ble_id bigint(19) DEFAULT NULL ,
batt_type tinyint(2) DEFAULT ‘-1’ ,
user_id bigint(19) DEFAULT NULL ,
comm_module_type tinyint(2) DEFAULT ‘0’ ,
meter_id bigint(19) DEFAULT NULL ,
material_number varchar(64) COLLATE utf8_general_ci DEFAULT NULL ,
zone_code varchar(30) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci DEFAULT NULL ,
zone_name varchar(60) COLLATE utf8_general_ci DEFAULT NULL COMMENT ‘基地名称’,
country_code varchar(30) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci DEFAULT NULL ,
country_name varchar(100) COLLATE utf8_general_ci DEFAULT NULL ,
source tinyint(2) DEFAULT NULL ,
smart_type tinyint(2) DEFAULT ‘-1’ ,
bt_unique_key varchar(64) COLLATE utf8_general_ci NOT NULL ,
experimental tinyint(2) NOT NULL DEFAULT ‘1’ ,
del_flag tinyint(2) DEFAULT ‘0’ ,
create_time timestamp(3) NOT NULL DEFAULT CURRENT_TIMESTAMP(3) ,
update_time timestamp(3) DEFAULT CURRENT_TIMESTAMP(3) ON UPDATE CURRENT_TIMESTAMP(3) ,
PRIMARY KEY (id) /*T![clustered_index] CLUSTERED */,
KEY i_bike_info_vin_create_time (vin,create_time),
KEY i_bike_info_create_time (create_time),
KEY i_bike_info_user (user_id),
KEY i_bike_info_iot_id (iot_id),
KEY i_bike_info_meter_id (meter_id),
KEY i_bike_info_ble_id (ble_id),
KEY idx_vbimdc (vin,ble_id,iot_id,meter_id,del_flag,create_time),
KEY idx_t_bike_info_sap_vin_normal (sap_vin),
KEY i_bike_info_experimental (experimental),
KEY idx_t_bike_info_bind_code_normal (bind_code)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_general_ci /*T![auto_rand_base] AUTO_RANDOM_BASE=4712456 */ ;

数据有没有大量写入，有没有可能region分裂，到别的节点上了

这几个表基本没有写入，只有读，region分裂的可能性很低啊

region分布

image1077×725 35.3 KB

读的数据有变化，刚好数据分散在不同的节点上了，不就换节点获取了

理想状态是 每个节点都有数据，足够分散就能够实现较小的资源获取更大的吞吐了

除了topSQL，可以通过dashboard 流量可视观察下，是不是这个表很亮，很亮就说明确实存在热点（也叫读偏斜或者写偏斜）

TIDB_HOT_REGIONS_HISTORY 可以看下这段时间热点region是不是同一个对象

热力图上都找不到这个表

查了下TIDB_HOT_REGIONS_HISTORY 都没这个表的记录

image1277×213 6.73 KB

说明你这个不是热力表

region有移动呗，先看下执行计划有没有能优化的

这个sql平均查询速度是40多毫秒，优化空间有限

image1240×51 2.71 KB

这个sql是做什么的，是不是类似于定时任务的，或者查近一段时间数据走的还是时间类型索引呢

不是定时任务，用户端调用的

这个情况符合嘛

不是查询一段时间的数据，是按照用户唯一id查询信息，结果只有一条。

哪没有思路了，看着节点状态基本是按着时间顺序压力变换，跟时间索引查询最近数据比较像，经过id查，看表结构是打散的，貌似不会这样，坐等大佬回复

TiDB Dashboard 流量可视化那个时间看看有哪些regions流量高