添加一个字段导致sql从2秒到7秒

为提高效率,请提供以下信息,问题描述清晰能够更快得到解决:
【 TiDB 使用环境】
v4.0.6

【概述】 场景 + 问题概述
查询sql
添加此字段7-11秒
未添加此字段 2-3秒


添加此字段的查询计划.csv (26.1 KB) 未添加此字段的查询计划.csv (25.9 KB)
【背景】 做过哪些操作

【现象】 业务和数据库现象

【问题】 当前遇到的问题

【业务影响】

【 TiDB 版本】

【附件】 相关日志及监控(https://metricstool.pingcap.com/)


若提问为性能优化、故障排查类问题,请下载脚本运行。终端输出的打印结果,请务必全选并复制粘贴上传。

这个字段是什么类型,看执行计划没有变化,但添加该字段后读取的数据量从几十兆增长到几百兆不等,将近10倍

image

2s 或 7s 在dashboard里应该都有记录。可以看看二者执行计划是否发生变化。

1赞


如果在sql中加入这个条件效率就会提升,但是与业务不符合
这是查询计划
加上条件后的执行计划.csv (27.4 KB)

执行计划已经发了

sql最终结果是一致的

jrtt_tools_video 这个表在SQL里用提示 /+READ_FROM_STORAGE(TIKV[table_name])/ 强制走下tikv,看看是不是能快些,多执行几次数据缓存后,后面是不是比第一次执行块

还是一样的7秒左右,而且加上url这个字段后查询到7秒的时候sql终端会很卡,但是2s的不会很卡

现在看就是加上这个字段后扫描的数据量增长了10倍,磁盘是什么类型的

磁盘是ssd,我后面发的加上id like '1’这个条件之后数据量是少了很多,逻辑也是没有错的,但是这个条件只适用于业务逻辑中的一种,还有很多种没办法走这个条件

加上条件过滤的数据量不一样,执行计划也变了

还有什么别的优化方法吗

你的新URL字段已经有插入值了吗?

是有值的

1、不要返回URL字段,确认下是否时间有减少
2、查看下这个URL的平均长度,在计算下返回的行数,推算下是否与返回增加的数据量对的上。

1.去掉url字段,时间减少5秒左右
2.最终返回行数,url字段增加的数据量是可以对上的

那就是由于增加了大字段导致的。大字段的表可以去了解下Titan存储引擎。

但是这个sql三个链接同时查询就会从7秒到24秒,效率太差了,我觉得还是有别的优化方法吧

tidb_distsql_scan_concurrency 这个参数调大调整看看