针对limit语句是有相关的优化，我记得是下推到tikv了

看了一些数据应该是没有大字段的，一行数据基本不会超过0.5KB，然后跟业务确认了一下，有些update会匹配到比较多的数据，比如几十万，然后我有疑问update不是加了limit 500了吗，还是会把所有符合条件的数据从tikv拿到tidb吗？

tidb内存高，后来我们是把gc时间从24h调整到2h，后来【 coprocessor executor count】指标才下来，然后重启tidb节点内存才没有飙升，之前重启tidb节点一会就又升上来了。 [image] 现在的疑问是，这个集群跑了很久了，gc一直都是24h，然后业务也没做什么变更上线之类，看慢查询的执行计划，不管update还是select，都是IndexLookUp，IndexRangeScan，改了gc时间以后，内存降下来了，执行计划也都是IndexLookUp，IndexRangeScan，搞不懂哪里出了问题，诱因是啥？ 另外 从出现问题到结束expensive…

没有了，帖子里面有贴

这个有解吗，能不能有什么操作可以规避一下呢

拿着我们发现的问题去提issue，甚至连日志都没动，有点厉害

是，通过edit-config查看到tiflash的部署信息，发现之前部署的时候6个端口都自定义了，然后挨个排查，最终定位到是metrics port跟别的服务冲突了。 PS: 那几个端口配的都比较大30000+，同事说这是操作系统临时端口段，很容易冲突，这次也是巧合，刚重启就被用了。 tcp_port: http_port: flash_service_port: flash_proxy_port: flash_proxy_status_port: metrics_port:

刚才试了一下，切换dashboard节点不行（切换前还先重启了待切换节点） 切换以后，慢查询列表能稳定展示，但是点详情还是报上面那个错误（找不到文件路径那个错误）

经过测试 set tidb_allow_mpp = off; set global tidb_max_tiflash_threads = 1 这两个操作都事可以的

普通索引也会报内存不足的错误。 [图片]

不会，我们之前也怀疑是因为tiflash占用内存过大导致，后来reload了tiflash节点重新测试还是一样的，重启了tiflash节点也能稳定复现。

从监控看不忙的，集群平均耗时也很低 [图片] [图片]

用了limit 1不代表我们的表很小，这个表有20多亿，只是偶然机会测出来发现这个现象，所以贴出来问一下

[图片] 这段话有点疑惑。 第一段说如果temp-dir不可用就会回退到非加速方式。 第二段说大于6.5版本的话会出现不可预知的问题。 所以哪个优先级更高，到底是会回退呢还是会出现异常？

这样去配置？ server_configs: tidb: temp-dir: /path/xxx

没找到这个参数呢 mysql> select version(); +--------------------+ | version() | +--------------------+ | 8.0.11-TiDB-v7.5.5 | +--------------------+ 1 row in set (0.00 sec) mysql> show global variables like '%temp%'; +------------------------+-------+ | Variable_name | Value | +----------…

所以说，采用默认参数装好的集群都没法对大表加索引呗？ 另外没看到temp-dir的配置项，只有tmpdir | tmpdir | /var/tmp/ |

这个查询是空的 [图片]

用的这个用户登录，是这个用户的权限不够无法打开这个功能吗？ mysql> show grants for root@'10.10.54.49'; +--------------------------------------------------------------------+ | Grants for root@10.10.54.49 | +--------------------------------------------------------------------+ | GRANT PROCE…