没试过 em 你看下 .em 的目录结果。 cd .em tree 结果发来看看

所以你其实是想删除 em 相关集群和 em 相关部署的东西？

我的意思是，你就当正常 tiup 使用有什么问题么？我理解你不就是想管理集群么？ tiup cluster list 这种直接敲什么结果呢。

看描述中控机有 .tiup 目录，你直接用 tiup 管理有报错么？ tiup cluster list 看看效果。

看标题，一边删、一般算。 如果你不是 select for update，我理解除非你删除自己有问题，不然不会死锁的。 不想幻读就用 RR 级别，但是读已提交更合理吧？

https://docs.pingcap.com/zh/tidb/stable/sql-statement-set-resource-group/ 有会话级别设置过么？可以按照这个文档看看登录这个账户后，绑定的资源组是哪个。

是不是大小写问题，有试过全小写么

就是自己同步自己了。 cdc 不分别自己的 tidb-server 节点的。你相当于同步任务创建到了下游。。。

所以是自己同步自己？

ticdc 缩容前，有删除 changefeed 的么？ 你可以试试扩容一个 ticdc，然后查看是否有 changefeed 残留。如果有删除掉。 如果没有你创建一个同名的 changefeed 删除，再缩容掉 cdc 试试。

tiup 安装不会拒绝的吧？他只是 check 不过罢了。 docker compose 部署不推荐。别折腾了。

[img_v3_02t3_1725f8a8-b7ed-48fd-b60e-e700f58f9b6g] 数据量比较多。 tidb-server cpu 高其实也就是用了 4vc+。 是 gc 任务导致的。tidb-server gc owner 要算一些东西和扫 lock 的。预期性能损耗。 别不给资源跑后台啊。这么大数据量和集群。

update 最新： 这个是 TiCDC 新架构已知问题：TiDB Dashboard Compatibility · Issue #2128 · pingcap/ticdc，后续会修复，应该不影响使用

我理解这可能是 ticdc 新架构和 dashboard 的兼容性问题。 我去问问。不过我理解不影响使用的。展示有问题？

tidb 测试开发可以使用 tiup playground 物理部署使用 tiup cluster 虚拟机可以使用 k8s + tidb operator docker compose 已经很久很久没有维护了。

我理解你是两个问题： 资源如果做隔离，cpu 内存等使用较高如何控制。 analyze 慢是否预期。 2 的话是预期的，和数据量有关。并且默认并发是 1 的跑。 1 的话可以参考混合部署相关文档：https://docs.pingcap.com/zh/tidb/stable/hybrid-deployment-topology/ 或者使用 cgroup 隔离：https://docs.pingcap.com/zh/tidb/stable/tiup-cluster-topology-reference/#tikv_servers 关键字：resource_control

不推荐使用 docker compose 来部署 tidb。 当前官网基本已经下线掉了相关部署说明，已经很久了。 开始的部署提供也只是提供一个快速的实验环境做的 如果想用虚拟化，当前推荐使用 k8s 等来安装，使用 tidb-operator 但是你们要考虑 你们有没有相关技术沉淀 有状态服务本身不推荐放 k8s 中。 运维成本在你们不熟悉 operator 代码和 k8s 相关技术的情况下成本是比较高的。 关于系统问题，你们如果想上生产，我理解服务器上应该只部署 tidb，也就是干净的服务器。升级下系统或者重装问题不大吧？ 如果是混合使用，这里不推荐。数据库尤其是生产是不推…

update 下 tidb index merge 失效原因： 对 tidb 来说原 query where 条件是 A or B and C 这种结构。IndexMerge 要么只能做 And， 要么只能做 OR， 是不能同时做 and 和 or 的。所以才导致了这个问题。 和对不对称关系不大