这才十几 MB/s ，就这么点 IO，需要关注不均衡的问题吗

参考这里，盘一般是分开用，官方建议单块不要超过 4 T https://docs.pingcap.com/zh/tidb/stable/hardware-and-software-requirements#生产环境 PD 一般部署 3 个，这个是分布式共识算法要求的最小数量，也是最常用的数量，具体根据你的高可用需求可以增加至 5、7 等基数个

有个系统视图查询当前活跃事务 SELECT * FROM INFORMATION_SCHEMA.TIDB_TRX\G

有长事务？是长时间不提交还是大事务？这个应该是会影响 cdc resolved ts 推进的，从而影响同步进度

lightning local 模式遇到过，你可以用 awk 分析下你的 csv 文件，还是比较快的

看下监控问题时段 Grafana 的 TiDB=》Transiaction=》Duration 面板，把监控表达式中的 0.99 调整为 1

覆盖是一个多危险的操作啊🤔，就算能覆盖，生产不建议这么玩

我只知道 TiDB 有个这个问题，就是记录带注释的 SQL 的时候会记录有点问题，一般也不影响用，像这样 [image] [image] 不知道你是不是这样的问题，你的图基本啥也看不到了，执行计划看着都是对的，你检查下看看吧

得具体分析了，现在没法确认

可以在日志中搜索下 expensive query 关键字看看， oom_record 有可能有时候没记录到

不能吧，现有的 ticdc 设计上是一个 tidb 集群的一部分组件，一个 ticdc 集群只能对一个 tidb 集群，部署上也没有看到 ticdc 单独部署的情况 k8s 上部署 ticdc 组件参考：https://docs.pingcap.com/zh/tidb-in-kubernetes/stable/deploy-ticdc 使用 tiup 在物理机环境部署 ticdc 组件： https://docs.pingcap.com/zh/tidb/stable/deploy-ticdc#使用-tiup-在原有-tidb-集群上新增或扩容-ticdc-组件

你那可能是有高资源消耗的 Sql ，或者系统哪里打满了

热点的解决方式是打散数据

精细化控制 SQL 是使用 TiKV 跑还是 TiFlash 跑，可以在 TiDB 层面分开

这样做目的是什么？

这么做的目的是什么呢？ TiDB 底层的 Region 会自动分裂和合并

Runaway query 这个功能应该是我最想用的，管理失控的 SQL

这 SQL 看起来是被影响的 SQL，没有别的慢 SQL 了吗

先看 sql 能不能调优