Distsql Duration 执行时间很长

【 TiDB 使用环境】生产环境
【 TiDB 版本】 v6.5.0
【复现路径】

SELECT
  r.`room_id`,
  t.`room_name`,
  t.`priority`,
  t.`creator`,
  t.`queue_size`,
  t.`description`,
  t.`speak_limit`
FROM
  `t_room_member` r
  INNER JOIN `t_room_info` t ON r.`room_id` = t.`room_id`
WHERE
  r.`member_id` = ?
  AND r.`room_id` > ?
  AND t.`delete_time` = 0
ORDER BY
  r.`room_id`
LIMIT
  ? [arguments: ("20000001142001", "", 500)]

DROP TABLE IF EXISTS `t_room_info`;
CREATE TABLE `t_room_info` (
  `id` bigint(20) NOT NULL /*T![auto_rand] AUTO_RANDOM(5) */,
  `room_id` varchar(32) NOT NULL  ,
  `room_name` varchar(32) NOT NULL ,
  `priority` int(11) NOT NULL,
  `creator` varchar(32) NOT NULL ,
  `queue_size` int(11) NOT NULL ,
  `description` text NOT NULL ,
  `create_time` bigint(20) NOT NULL,
  `rorg_id` varchar(32) NOT NULL ,
  `delete_time` bigint(20) NOT NULL ,
  `speak_limit` int(11) NOT NULL DEFAULT '120' ,
  PRIMARY KEY (`id`) /*T![clustered_index] CLUSTERED */,
  UNIQUE KEY `idx_room_id` (`room_id`),
  KEY `idx_room_creator` (`creator`),
  KEY `idx_rorg_id_room_id` (`rorg_id`,`room_id`),
  KEY `idx_rorg_id_create_time` (`rorg_id`,`create_time`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin /*T![auto_rand_base] AUTO_RANDOM_BASE=570001 */;



DROP TABLE IF EXISTS `t_room_member`;
CREATE TABLE `t_room_member` (
  `id` bigint(20) NOT NULL /*T![auto_rand] AUTO_RANDOM(5) */,
  `room_id` varchar(32) NOT NULL ,
  `member_id` varchar(32) NOT NULL ,
  `priority` int(11) NOT NULL ,
  `create_time` bigint(20) NOT NULL ,
  `speak_limit` int(11) NOT NULL ,
  `rorg_id` varchar(32) NOT NULL ,
  PRIMARY KEY (`id`) /*T![clustered_index] CLUSTERED */,
  KEY `idx_member_id` (`member_id`),
  UNIQUE KEY `index_roomID_userID` (`room_id`,`member_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin /*T![auto_rand_base] AUTO_RANDOM_BASE=280388601 */;

使用语句如下:
【资源配置】
CPU:16核 内存:128G 磁盘20T
TIDB配置全部默认走的tiup安装




看下tikv detail → thread cpu 、检查这段时间QPS是否增长看看慢SQL,看看CPU利用率,检查这段时间的IO和网络



cpu瓶颈了 应该有大量读吧

读的数量不是很大

之前使用没有问题.我是三台如上配置的机器, 原来都是ubuntu20.04 后来一台重装了ubuntu22.04 完事我重新构建的集群 再跑业务就这样了

你这个sql看着问题不大,为什么单独提出来?

这是物理机部署吗 ? 多少CPU ,show config where name like '%readpool%max-thread-count% , 看看其他慢SQL

移动云kvm的

这个sql 非常慢

你提供的sql看起来就1秒多执行时间,如果没有其他大数据量或大并发的sql,估计是环境问题,我遇到过k8a由于cgroup设置不对导致的只要有sql.起来read pool cpu就很高,但我那个是一直持续的,我感觉你这个也属于类似问题

看看qps变化,tidb监控页

qps增加和duration一致,但是为啥能把cpu打满,还得分析下sql,执行计划

毛sql? 你需要啥我给你截图

??? 我确实不知道毛sql啥意思 我寻思你要分析的话 我给你截图