大量的空region产生,会导致数据库响应时间变慢吗?

【 TiDB 使用环境】生产环境
【 TiDB 版本】v 7.5.2
【遇到的问题:问题现象及影响】

昨天数据库单台TiDB主机,响应时间突然变慢,产生了大量的慢查询,没有定位到问题原因。

查看面板的时候发现有大量的空region产生。期间数据库没做什么其他操作,只是建了一个如下的分区表。

期间我们的处理方法是:将数据库连接切换到另一台TiDB主机是,数据库就恢复正常了

CREATE TABLE test.`tmp_std_DeviceEvent_Clue` (
  `id` bigint(20) NOT NULL /*T![auto_rand] AUTO_RANDOM(5) */ COMMENT '随机Id',
  `_$tidx` tinyint(4) NOT NULL COMMENT '从sql server同步过来的分表索引,如std_DeviceEvent64,则同步值为64',
  `EventID` bigint(20) NOT NULL COMMENT 'sql server的主键',
  `OldEventID` bigint(20) NOT NULL DEFAULT '0',
  `ObjectID` bigint(20) NOT NULL,
  `EventType` int(11) NOT NULL,
  `EventTime` datetime NOT NULL,
  `Lng` decimal(18,6) NOT NULL,
  `Lat` decimal(18,6) NOT NULL,
  `Speed` int(11) DEFAULT NULL,
  `Direct` int(11) DEFAULT NULL,
  `GPSTime` datetime NOT NULL,
  `KeyVideoUrl` varchar(256) NOT NULL,
  `KeyVideoPath` varchar(256) NOT NULL,
  `KeyThumUrl` varchar(256) DEFAULT NULL,
  `OriVideoPath` varchar(256) NOT NULL,
  `RelVideoPath` varchar(256) DEFAULT NULL,
  `CreateTime` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  `UpdateTime` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '修改时间',
  `isLoved` bit(1) DEFAULT b'0',
  `KeyImageUrl` text DEFAULT NULL,
  `isShare` bit(1) DEFAULT b'0',
  `SerialNumber` varchar(33) DEFAULT NULL,
  `tmpUrl` varchar(128) DEFAULT NULL,
  `processFailState` int(11) DEFAULT NULL,
  `isDeleted` bit(1) DEFAULT b'0',
  `Source` smallint(6) DEFAULT '0',
  `City` varchar(30) DEFAULT NULL,
  `channel` bigint(20) NOT NULL DEFAULT '0',
  `uid` bigint(20) NOT NULL DEFAULT '0',
  `callbackUrl` varchar(255) DEFAULT '' COMMENT '',
  `EventSource` tinyint(4) NOT NULL DEFAULT '0' COMMENT '',
  `KeyImageList` text DEFAULT NULL COMMENT '',
  `KeyVideoList` text DEFAULT NULL COMMENT '',
  `rv` bigint(20) NOT NULL COMMENT '',
  `SRContent` text DEFAULT NULL COMMENT '',
  `GsensorUrl` varchar(200) DEFAULT '' COMMENT '',
  `ConfigId4s` int(11) NOT NULL DEFAULT '0' COMMENT '',
  `BigDataMark` tinyint(3) NOT NULL DEFAULT '-1' COMMENT '',
  `aiMark` tinyint(3) NOT NULL DEFAULT '-1' COMMENT '',
  `HoldID4s` int(11) NOT NULL DEFAULT '0' COMMENT '',
  `FinalMark` tinyint(3) GENERATED ALWAYS AS (if(`aiMark` = 1, 1, `BigDataMark`)) VIRTUAL,
  `DiffSecond` bigint(20) NOT NULL DEFAULT '0' COMMENT 'CreateTime与EventTime相差的秒数(CreateTime减去EventTime), 单位:秒',
  PRIMARY KEY (`id`,EventTime) /*T![clustered_index] CLUSTERED */,
  UNIQUE KEY `UK_EventID_$tidx_EventTime` (`EventID`,`_$tidx`,EventTime),
  KEY `idx_EventTime_EventType` (`EventTime`,`EventType`),
  KEY `idx_CreateTime_BigDataMark` (`CreateTime`,`BigDataMark`),
  KEY `idx_configId4s_EventTime_EventType` (`ConfigId4s`,`EventTime`,`EventType`),
  KEY `idx_HoldID4s_EventTime` (`HoldID4s`,`EventTime`),
  KEY `idx_FinalMark` (`CreateTime`,`FinalMark`),
  KEY `idx_ObjectID_EventID_EventType` (`ObjectID`,`EventID`,`EventType`),
  KEY `idx_ObjectID_EventTime` (`ObjectID`,`EventTime`),
  KEY `idx_EventTime_DiffSecond` (`EventTime`,`DiffSecond`),
  KEY `idx_CreateTime_DiffSecond` (`CreateTime`,`DiffSecond`),
  KEY `idx_CreateTime_DiffSecond_HoldID4s` (`CreateTime`,`DiffSecond`,`HoldID4s`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin /*T![auto_rand_base] AUTO_RANDOM_BASE=610151301 */
PARTITION BY RANGE COLUMNS (EventTime)
INTERVAL (1 day) FIRST PARTITION LESS THAN ('2024-01-01') LAST PARTITION LESS THAN ('2050-12-31');

创建分区表时,如果使用了不合理的预分裂策略,比如大量的空分区,也可能会导致空 Region 的产生;大量空 Region会导致频繁的merge也会影响region的分配调度等;建议检查一下分区是不是合理

就是按天分区呢。还是说建表一次性预分配太多分区,会有影响?

2024-2050啊,建了20多年的,一天一张,这有点儿太多了吧,但是不知道是不是这个原因

分区建立太多是会这样,正常 split table 参数为 true,会为每一个分区分配一个 Region,正常来说 split region 也不会影响你的查询,你的查询也不会落到当前正在 split 的上边
可以看下慢查询日志分析下为什么会有慢查询

可以考虑看下dashboard中的慢查询,在这边可以看到这些慢查询SQL执行过程中各个阶段的执行时间

空region会导致响应变慢的。我们遇到过。最后把空region都合并了,就好了。

1 个赞

觉得是分区策略太细了,导致产生大量空白无效的region


你们也是遇见了这种情况吗?


第二次创建分区数量设置了只有三百多个,也会出现空region,但是不会出现响应变慢。可能是没有到达那个分区量级

我们这边的分区策略是按天分区呢,应该不算太细吧。会不会是一次性建立分区太多

看了下,这些慢查询,正常情况下查询都是0.01s,当时就是响应时间到达3s了

这 SQL 看起来是被影响的 SQL,没有别的慢 SQL 了吗


有呢,这些sql现在数据库正常情况下,执行都很快的0.1s内

当时的慢sql,在现在数据库正常的情况下执行很快的,0.1s内。当时响应时间都到2-3s

应该是分区策略不合理造成的,至少当前日期到2050之间的分区目前都是空的,目前也不会有数据,可以根据主键或者业务的使用情况对表分区

你那可能是有高资源消耗的 Sql ,或者系统哪里打满了

现在就不太确定这次故障是不是由于创建的分区表引起的。我们这边业务需求就是需要按天分区呢,按天来查询的比较多。

那就不是分区表分区不合理引起故障的吗?

得具体分析了,现在没法确认