执行计划跳变本身也是低概率事件。。。。或者是不是 sql 给的传参不一样？ 比如查 1 天和查 1 年的数据分布肯定是不一样的。

我复现案例对么。或者你能提供复现案例么？ 能复现的话 我找人看看。。。

mysql --comments --host 127.0.0.1 --port 4000 -u root Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 513802246 Server version: 8.0.11-TiDB-v8.5.1 TiDB Server (Apache License 2.0) Community Edition, MySQL 8.0 compatible Copyright (c) 2000, 2021, Oracle and/or i…

官网有啊： https://docs.pingcap.com/zh/tidb/stable/encryption-at-rest/#通过-kms-指定主密钥 [image]

测试测试，可以做个升级计划。 降级不推荐呢

降级干啥。。。降级不如升级。明年讲不好就是 9.0 版本了

感觉能接受就先不着急升级。 不行就升级 8.5.3 版本看看。。。对应报错异常代码，8.5 已经去掉这部分逻辑了。

你们 tikv crash 了么？ 影响尚可的话就先不急？

应该类似这段代码： CDC 组件在 delegate.rs:878 处（对应提供代码的 630-636 行）的断言失败 解决方案 PR #17274 - “cdc: re-design delegate and downstream to support partial region subscription better” 该 PR 在 v8.0 到 v8.3 版本之间重构了 CDC 的 Delegate 和 Downstream 组件： 主要改进: 移除了这个过于严格的断言 重新设计以更好地支持部分区域订阅： 增量扫描现在可以在订阅的范围内执行，而不是整个 region 如…

要不升级到： * 7.5.7: 2025-09-04 两个小版本我感觉闭眼升。

其实就是看公司领导决策和方针。下面干活的其实选择权不大。 学的多竞争力强一些，有好有坏吧。现在的就业环境，忙点也好，有钱赚。 tidb 有工具支持 Oracle协议存储过程转 java。

检查 tikv.toml 中的 [security.encryption.master-key] 配置 关键配置： [security.encryption.master-key] vendor = "xxx" [security.encryption.master-key.xxx] # 此处添加 KMS 的特定认证信息 # 包括但不限于： # - endpoint: KMS 服务地址 # - key_id: 主密钥 ID # - region: 区域信息（如适用） # - 认证凭证相关配置

request timeout. duration: 10s get data key failed TiKV 无法在 10 秒内从 AWS KMS 获取数据密钥，导致超时失败。 看起来还是配置问题

[image] 统计信息不准吧

整个过程 tikv 是停机的么？

[image] 这个截图看起来就是你有两个执行计划，第二个执行计划应该不太好导致的。 1、可以定期收集统计信息保证统计信息的准确性 2、可以加 bind 来固定执行计划：https://docs.pingcap.com/zh/tidb/stable/sql-plan-management/

https://docs.pingcap.com/zh/tidb/stable/tidb-resource-control-runaway-queries/#管理资源消耗超出预期的查询-runaway-queries 可以用 query watch 来指定这类 sql ，到达一定时间后进行 kill

node export 用的不是 tidb 自带的么？

[image] 这个呢。