手动试explain analyze内存消耗小，running_sql里有些参数化的in多条件查询，可能in条件多耗内存

0 Bytes的不确定文件中SQL内存消耗是否准确

看是没啥占内存高的SQL record2024-12-18T08:19:31+08:00]# grep ‘mem_max:’ running_sql mem_max: 280736 Bytes (274.2 KB) mem_max: 45294 Bytes (44.2 KB) mem_max: 25640 Bytes (25.0 KB) mem_max: 159 Bytes (159 Bytes) mem_max: 0 Bytes (0 Bytes) mem_max: 0 Bytes (0 Bytes) mem_max: 0 Bytes (0 Bytes) mem_max: …

10号这配置调整为off后，还是出现内存抖增问题了 [image-20241223105851296] [PixPin_2024-12-23_11-02-13]

配置灵活不了，云主机nvme本地盘12c 96g规格是死的，仅只有一种… tidb-server平时大多数时候内存消耗很低4G左右，

这参数我后面再试试；计算16G内存，平时大多数时候tidb-server使用内存低4G左右

截图补充了10分钟内慢查询没有大耗时，大内存情况，内部sql情况

并没有高QPS情况，高并发QPS下内存上涨是能说通；截图补充了10分钟内慢查询没有大耗时，大内存情况

做好测试验证，备份

多个计算节点情况是可以这样

看之前已经升级成功7.5.4一套tidb集群计算节点是没这2目录

v6->v7之前做过次6.1.5->7.5.4没遇到这问题，建议升级还是先用新建套独立测试环境来做，这次升级失败的是业务测试环境（影响不大，升级前最好做次全量备份），好几个业务方在问好久可用

update 一直没执行过成功，应用程序超时终止了，无法通过历史执行计划来创建binding 根据SQL创建强制索引bind没生效，最后还是收集表索引统计信息完后才走索引正常 mysql> ANALYZE TABLE xxxx_data INDEX idx_standard_xxxx; Query OK, 0 rows affected (4 hours 16 min 57.41 sec)

并发是早上已经增大4倍多到18了 mysql> show global variables like '%tidb_build_stats_concurrency%'; +------------------------------+-------+ | Variable_name |…

目前问题已解决，关掉计算节点执行计划缓存后，页面报表查询响应快，符合预期（走到了正确联合索引）

还真可能和plan cache有关，我验证下，之前另一套高TPS的TiDB集群计算节点内存一直涨，关闭执行计划缓存后内存就正常了

是的了

TiDB冷数据我们已经有用SAS机械盘的了，但机械盘可靠性不是很高，机械盘我们已经维护换盘过几次了，而且机械盘基本在自建idc才有，对象存储的可靠性，适配性更好