【 TiDB 使用环境】生产环境
【 TiDB 版本】7.2
【复现路径】慢SQL
【遇到的问题：问题现象及影响】
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件：截图/日志/监控】
使用tiflash，出现的慢SQL，sql语句如下：
SELECT
title,
description,
content,
domain,
id,
esId,
keyword
FROM
general_monitoring_1685427644559
WHERE
1 = 1
ORDER BY
id
LIMIT
89207843, 100;
补充一下，以上SQL执行，需要22分钟
这个 SQL 的业务逻辑是啥，单表深分页场景，能否从业务上优化
目前提供的信息有点少，不好分析原因，请给出这个表的表结构还有执行计划
建议也到Dashboard页面上确认下这个SQL慢在哪个环节，可以很直观看到分析过程
如果明确知道要走什么引擎 走什么索引，手动指定下
执行计划最好发一下
慢查询记录、查询计划、索引情况补充一下
执行计划发一下
这个问题已经优化了，直接改写SQL，mysql 或TIDB使用limit offset和limit。只针对小表。
如果上亿的打表，执行计划将非常糟糕。具体我没有收集。
OFFSET 和 LIMIT 对于数据量少的项目来说是没有问题。但是，当数据库里的数据量超过服务器内存能够存储的能力，并且需要对所有数据进行分页，问题就会出现。
为了实现分页，每次收到分页请求时，数据库都需要进行低效的全表扫描。
什么是全表扫描？全表扫描 (又称顺序扫描) 就是在数据库中进行逐行扫描，顺序读取表中的每一行记录，然后检查各个列是否符合查询条件。
这种扫描是已知最慢的，因为需要进行大量的磁盘 I/O，而且从磁盘到内存的传输开销也很大。
这意味着，如果你有 1 亿个用户，OFFSET 是 5 千万，那么它需要获取所有这些记录 (包括那么多根本不需要的数据)，将它们放入内存，然后获取 LIMIT 指定的 20 条结果。
优化方法：
改写SQL
改为id >89207843 limit 100即可。
大佬厉害
学习了
，改完之后，运行时间是多少？
id 字段有索引吧？
学习了
skip limit本来就是效率不高
创建表为聚簇表，走tikv 试试
单表查询，没有where条件，order by 。
具体表数据量？id是否是索引？
统一回复，优化之后执行时间0.01秒，id是主键索引