大数据量单表查询,单次查询需要一两面,高并发查询的情况下,单条sql查询时间就增加了几十倍

CREATE TABLE log_data (
id bigint NOT NULL COMMENT ‘主键(显示雪花算法生成)’ ,
ser_num varchar(30) COLLATE utf8mb4_general_ci DEFAULT NULL COMMENT ‘序列号’,
status bigint DEFAULT NULL COMMENT ‘状态’,
req_num int DEFAULT NULL COMMENT ‘次数’,
req_date datetime DEFAULT NULL COMMENT ‘时间’,
KEY idx_ser_num (ser_num) COMMENT ‘ser_num’,
KEY idx_req_date (req_date) COMMENT ‘req_date’
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci COMMENT=‘记录’
PARTITION BY RANGE COLUMNS(req_date)
(PARTITION p20250915 VALUES LESS THAN (‘2025-09-16 00:00:00’),
PARTITION p20250916 VALUES LESS THAN (‘2025-09-17 00:00:00’));

该表50亿+数,
SELECT
ser_num,
req_date,
status,
req_num
FROM
log_data
WHERE
(
ser_num= ?
AND req_date>= ‘2025-09-16 00:00:00’
AND req_date< ‘2025-10-17 00:00:00’
AND req_dateIS NOT NULL
)
ORDER BY
req_dateASC 单次执行需要2秒,如果并发同时执行,单条执行时间变成几十秒( 并发执行sql查询的时候,服务器内存使用率飙升

多次同时执行;多条SQL争用资源(cpu,内存,磁盘io)的情况;执行时间会增加的。

搞一个组合索引。。

ser_num,req_date的组合使用。试试

表数据量太大了,更改索引难度很大

看了你的SQL,缺乏联合索引 ,导致高并发下大量回表和锁竞争,建议创建联合索引ser_num, req_date

这种操作肯定会增加一致性读锁

你的查询条件是 req_date >= '2025-09-16' AND req_date < '2025-10-17' 。这跨越了 p20250916 以及之后多达31个未定义的分区 。TiDB无法进行有效的分区剪裁,它必须扫描所有分区(包括未来的空分区)