【部署方式】云上部署（什么云）/机器部署（什么机器配置、什么硬盘）
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
这两个背景信息给一下
1 天前
执行 ALTER TABLE move_call_tx_new REORGANIZE PARTITION pmax INTO (...) 操作时， 仅会复制 pmax 分区 ，但如果表存在 全局索引（GLOBAL Indexes） ，则需要同步更新全局索引，这可能导致 CPU 资源消耗过高及锁等待超时。
对于大表（如日增 3 亿行的表），直接使用 ALTER TABLE t PARTITION BY 会重组整个表，成本极高；建议通过脚本提前准备分区，例如每月执行一次 REORGANIZE PARTITION 操作，避免一次性处理大量数据
2 天前
请问是哪个版本的问题？
集群的部署情况是什么样的？
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
这个可以发一下
2 天前
互助交流区资源隔离 RU 掉 0 问题修复
之前存在的问题：集群在负载不均衡的情况下会出现可用 RU 掉 0，导致 SQL 执行耗时增加
问题原因：集群 RU 算法存在缺陷
修复后解决了热点资源分配问题
TiKV 流控与 RocksDB 流控参数解耦
解耦 TiKV 流控与 RocksDB 流控参数
之前存在的问题：当前 TiKV 流控与 RocksDB 流控参数存在强耦合设计，导致参数互相影响
解耦后效果：RocksDB 参数将无需手动干预
MCC 内存引擎优化
该功能在 v8.5.4 版本中提供，用于优化热点数据更新场景
适用场景：频…
4 天前
TiDB 2PC 事务流程特性 ：TiDB 的 2PC 事务提交流程中，在 primary key 所在 region 的 commit 成功后，会 异步并发 向剩余 region 发起 commit 请求。这意味着 primary 提交成功仅代表事务决议完成，但 secondary keys 的 commit 是异步执行的，若 secondary commit 失败（如 LockNotExist 等错误），可能导致部分数据未持久化，从而出现“写入的数据没查到”的现象。
已知 bug 及规避方案 ：你遇到的问题可能与 async-commit 模式下的 PessimiticLockN…
5 天前
+1 建议还是用 tiup 部署，可以试一试 tiup 能不能部署起来，部署不起来再考虑升级操作系统的版本，要不然你生产环境下也不安全。建议安装官方的部署文档的部署要求来做。
5 天前
没有更多内容了