tidb 查询表中不存在的数据时，执行 select x from xxx order by xxx limit 10, offset 0 会变成全部扫描，查询缓慢

Hacker_b0cygNCC · 2023 年9 月 1 日 02:26

【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】
【复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
【资源配置】
【附件：截图/日志/监控】

大飞哥Boil · 2023 年9 月 1 日 02:28

我去环境试试

Hacker_b0cygNCC · 2023 年9 月 1 日 02:28

如何解决这个问题？，查询时不知道是否存在，如果每个分页查询时都要先判断是否存在，这是十分麻烦，违反正常用户习惯

Hacker_b0cygNCC · 2023 年9 月 1 日 02:31

去掉，limit 和 order 都能秒返回，不存在的数据中，加上order 和 limit 执行引擎就走偏了

大飞哥Boil · 2023 年9 月 1 日 02:34

我这表是200W的，查了不存在的book_id，没有出现你的问题

大飞哥Boil · 2023 年9 月 1 日 02:34

analyze table 跑一下，再看看呢

大飞哥Boil · 2023 年9 月 1 日 02:35

我的版本是v7.1.0的

Hacker_b0cygNCC · 2023 年9 月 1 日 02:39

我也是7.1.0

就110多万数据，执行2.2秒，

zhe这里全是慢查询

Hacker_b0cygNCC · 2023 年9 月 1 日 02:40

= 过滤也超时啊

大飞哥Boil · 2023 年9 月 1 日 02:44

表结构上一波

Hacker_b0cygNCC · 2023 年9 月 1 日 02:45

你的查询order by 有问题，你的order by user_id 应该很少，我的order by 是时间，时间。我用一个order by 很少的字段也快啊

Kongdom · 2023 年9 月 1 日 02:45

有热点或者ddl阻塞么？

Hacker_b0cygNCC · 2023 年9 月 1 日 02:46

create_at datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT ‘数据创建时间’,
update_at datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '数据更新时你就搞成按时间 order 试下就知道

Hacker_b0cygNCC · 2023 年9 月 1 日 02:47

qps 就5以内，没人访问，就是tidb 执行引擎走错了

大飞哥Boil · 2023 年9 月 1 日 02:48

order by rated_at 也挺快啊

Hacker_b0cygNCC · 2023 年9 月 1 日 02:51

CREATE TABLE SyncLogRecord (
a bigint(20) unsigned NOT NULL /*T![auto_rand] AUTO_RANDOM(5) */,
b bigint(20) NOT NULL,
c datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,
d datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
e varchar(255) COLLATE utf8mb4_general_ci NOT NULL DEFAULT ‘video’,
f int(11) NOT NULL,
g int(11) NOT NULL,
h int(11) NOT NULL,
i varchar(255) COLLATE utf8mb4_general_ci NOT NULL,
j varchar(255) COLLATE utf8mb4_general_ci NOT NULL,
k varchar(255) COLLATE utf8mb4_general_ci NOT NULL,
l varchar(255) COLLATE utf8mb4_general_ci NOT NULL,
m varchar(255) COLLATE utf8mb4_general_ci NOT NULL,
n varchar(255) COLLATE utf8mb4_general_ci NOT NULL,
o int(11) NOT NULL,
p int(11) NOT NULL,
q text COLLATE utf8mb4_general_ci NOT NULL,
r varchar(255) COLLATE utf8mb4_general_ci NOT NULL,
s int(11) NOT NULL,
t varchar(255) COLLATE utf8mb4_general_ci NOT NULL DEFAULT ‘’,
u varchar(255) COLLATE utf8mb4_general_ci NOT NULL DEFAULT ‘’,
v varchar(255) COLLATE utf8mb4_general_ci NOT NULL DEFAULT ‘’,
w varchar(255) COLLATE utf8mb4_general_ci NOT NULL DEFAULT ‘’,
x varchar(255) COLLATE utf8mb4_general_ci NOT NULL DEFAULT ‘’,
y varchar(255) COLLATE utf8mb4_general_ci NOT NULL DEFAULT ‘’,
z text COLLATE utf8mb4_general_ci NOT NULL,
aa smallint(6) NOT NULL DEFAULT ‘0’,
ab int(11) DEFAULT NULL,
ac varchar(255) COLLATE utf8mb4_general_ci DEFAULT NULL,
ad varchar(255) COLLATE utf8mb4_general_ci DEFAULT NULL,
ae int(11) NOT NULL DEFAULT ‘0’,
af tinyint(1) NOT NULL DEFAULT ‘0’,
PRIMARY KEY (a) /*T![clustered_index] CLUSTERED */,
KEY logrecord_b (b),
KEY logrecord_c (c),
KEY logrecord_g (g),
KEY logrecord_h (h),
KEY logrecord_l (l),
KEY logrecore_i (i)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;

Hacker_b0cygNCC · 2023 年9 月 1 日 02:58

好像是tidb 时间解析的bug，tidb 不知道datetime 可以比较，我用表里其他字段 int 类型order 和 string 类型 order , 其他列，都能很快返回

Hacker_b0cygNCC · 2023 年9 月 1 日 02:59

Hacker_b0cygNCC · 2023 年9 月 1 日 03:06

就这个最简单的首页列表需求，按时间倒序排，就查一个字段,100w数据，order by limit offset 都有问题，这个得赶紧解决了，不解决根本没有用

Hacker_b0cygNCC · 2023 年9 月 1 日 03:13

解释不清楚，create_at,不行update_at 就行， create_at datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT ‘数据创建时间’,
update_at datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT ‘数据更新时间’, 这肯定是tidb 的bug, 时间是数据库填充的