为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：
【 TiDB 使用环境】
v4.0.6
【概述】 场景 + 问题概述
查询sql
添加此字段7-11秒
未添加此字段 2-3秒
【现象】 业务和数据库现象
【问题】 当前遇到的问题
【业务影响】
【 TiDB 版本】
【附件】 相关日志及监控（https://metricstool.pingcap.com/)
若提问为性能优化、故障排查类问题，请下载脚本运行。终端输出的打印结果，请务必全选并复制粘贴上传。
这个字段是什么类型，看执行计划没有变化，但添加该字段后读取的数据量从几十兆增长到几百兆不等，将近10倍
2s 或 7s 在dashboard里应该都有记录。可以看看二者执行计划是否发生变化。
执行计划已经发了
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 这个参数调大调整看看
