我给你做了个错误的示范，希望你能理解，发泄情绪无助于解决问题。

没关系，你逮着我反问？？？？？ 你现在知道和我没关系了？？？？？

谁没情绪？ 我也有，你这一串问号，我也可以有情绪了不是么？

你要骂公司我真觉得没啥问题。我支持你骂。 因为他们拿钱办事，这个事确实应该做好。 但文档也是开源的，写文档的人可能不一定是他们公司的。人家也是为爱发电，又没收钱，你火气这么大，连话都不想好好说，就没有必要了不是么

所以你是来发泄情绪的，解决问题还在其次是这么个意思？

你现在这不是能好好说话么。文档有问题，可以改的嘛。 你弄的一副他文档写的不好，他就该死的样子就没有必要了吧。

有事就说事么，何必这么大火气呢

不是，没sudo权限的话，tiup打不开对应的limits文件吧？ 所以就一直查不到，以为你设置的是一个默认值。

以前查询分区表性能下降是因为没有全局索引，有全局索引以后应该是好很多。 建议好好看看这个。

不是执行计划的问题，执行计划其实是一样的，只是个别算子名字可能有变化。 问题出在actrows上，实际扫描的数据量有了数量级的差异造成的。 建议用where条件中的4个列，单独建一个索引试试。

[5cabd5ff-e075-49d8-8527-a5b00ea109c0] 你上面日志里面写着不能读取。 我感觉还是你组的raid5有点问题。 重点测试一下读取方面，真的没问题嘛？ tidb本来也是多副本的，用raid其实会降低性能。如果数据真的重要还是提高副本数量会更好。

单副本还是通过max-replicas来设置好些。 https://docs.pingcap.com/zh/tidb/stable/pd-configuration-file/#max-replicas

这个里面，你直接点进去应该能看到这个1.3g的内存是那个算子用的最多。执行计划的列很多，往后拖应该能看到。 感觉这个执行计划有点问题。limit算子不太应该用这么内存，如果加order by我是能理解的。现在这个1.3g就很难理解用在哪里了。

其实很正常，大概率他已经有自己的一套监控了。

我怎么怀疑是网络出错了呢。 因为你执行tiup list dm-master能明显看到的。 v8.5.0 2024-12-19T06:27:40Z darwin/amd64,darwin/arm64,linux/amd64,linux/arm64 liunx+amd64这个组合是肯定有的。不应该报这个错。

https://docs.pingcap.com/zh/tidb/stable/tiup-cluster-topology-reference/#monitoring_servers 一开始的部署拓扑文件里面也有对应的配置，修改一下就好了，从这个地方改可能更好。 monitoring_servers 约定了将 Prometheus 服务部署到哪台机器上，同时可以指定这台机器上的服务配置，monitoring_servers 是一个数组，每个数组元素包含以下字段： host：指定部署到哪台机器，字段值填 IP 地址，必填项 ng_port：指定 NgMonitoring 组件监听的端口…

9090应该是 Prometheus的端口。 参考下面这个

我试了下。7.5.6下执行计划确实有问题。需要加hint explain select statistics_date,count(1) from merchant_assessment_day_warn_detail use index(idx_create_time) where create_time between ‘2025-08-20 00:00:00’ and ‘2025-09-09 00:00:00’ group by statistics_date order by statistics_date; 加个use index就变回来了。另外最新版本v8.5.3…

你这个sql如果删除的很慢，我是能理解的，但是直接oom。就有点奇怪了。 最好是能看看执行计划。 建议尝试一下非事务删除，看是否能运行下去。 https://docs.pingcap.com/zh/tidb/stable/dev-guide-delete-data/#非事务批量删除 另外你6.5.1可能会有些bug导致出现超大的region,也可能导致删除的时候扫描不动。 [image] 建议查一下grafana里面这个oversized region count是不是0.