单个分区几十亿数据，查单个mobile某个分区的一天的数据(几万条左右)，为什么要十几秒

🪐 TiDB 技术问题
1

【TiDB 使用环境】测试
【TiDB 版本】8.5.3
【操作系统】Rocky Linux release 9.6
【部署方式】虚拟机4核16G200GSSD *3
【集群数据量】
单表30亿
【集群节点数】3节点
【问题复现路径】单表分区查询缓慢
【遇到的问题：问题现象及影响】
CREATE TABLE log_record (
mobile varchar(64) COLLATE utf8mb4_general_ci NOT NULL COMMENT ‘log_number’,
record_time datetime DEFAULT NULL COMMENT ‘record_time’,
KEY idx_vin (mobile) COMMENT mobile索引’,
KEY idx_record_time (record_time) COMMENT ‘record_time索引’
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci /*T! SHARD_ROW_ID_BITS=3 PRE_SPLIT_REGIONS=3 */ COMMENT=‘通话记录’
PARTITION BY RANGE COLUMNS(record_time)
(
PARTITION p202508 VALUES LESS THAN (‘2025-09-01 00:00:00’),
PARTITION p202509 VALUES LESS THAN (‘2025-10-01 00:00:00’),
PARTITION p202510 VALUES LESS THAN (‘2025-11-01 00:00:00’),
PARTITION p202511 VALUES LESS THAN (‘2025-12-01 00:00:00’),
PARTITION p202512 VALUES LESS THAN (‘2026-01-01 00:00:00’),
PARTITION p202601 VALUES LESS THAN (‘2026-02-01 00:00:00’),
PARTITION pFuture VALUES LESS THAN (MAXVALUE));
这个表结构，单个分区几十亿数据，查单个mobile某个分区的一天的数据(几万条左右)，为什么要十几秒
【资源配置】

2

单个分区还是显得太大了一点
索引上，应该使用复合索引

3

执行计划贴一下

4

要看下执行计划，大概率没有命中分区

5

:yum:之前用分区表的时候，分区表内不走索引。不知道现在走不走。看一下执行计划就知道了

6

感谢各位，我来反馈下相关人员看看执行过程 :pray:

1 个赞
7

查询慢的主要原因是缺少 mobile, record_time联合索引，且查询条件未正确触发分区。

9

你们试试不分区得聚簇表，分区除了删除数据方便真没啥用

10

查看一下过滤条件是否使用了索引

11

执行计划贴一下.

12

一个是要看下执行计划，一个是作为AP计算的节点，虚拟机4核16G的资源，对于单个分区几十亿的数据来说可能发挥不出并行计算的优势。

先给出具体的执行计划、节点资源CPU、内存、磁盘IO等使用监控来综合分析吧

1 个赞
13

建议贴下执行计划