查了下资料 说是可以， 没实操过

Owner 会生成 /tmp/tidb临时目录 和相关文件 报错是权限不足 chown tidb:tidb /tmp/tidb 试下能否解决

TiDB CDC 监听的是 具体的表名 默认不会自动同步新的表 不会被原有任务自动接管。 Kafka 端是按主题 / 分区接收数据 总之没这么想当然的智能

topic 还能对得起来吗

乐观积极拥抱

看描述 是uint32 限制。不是bug。

学习知识的好办法，善于总结， get到了。

very good

是不是这个原因呢? 流水线 DML（bulk）会大量占用 TiDB 后台资源（gRPC、chunk、write 线程），导致应用端的【读请求】被排队、阻塞、等待资源，所以应用返回慢； 但数据库直连不走应用连接池，不受排队影响，所以查得快。

客户端执行只需要算出子查询最终会返回多少行数字。应用端执行可能处理的数据比较大。组装 计数 传输的销售比较大

新的分布式执行框架（DXF）导致的等待 关闭pipeline试试

不能用别名 是bug的话，那太低级了。

[图片] 这个扩容后的截图？ 缺失大量region副本

没明白

学习学习

开放性问题。

topology.yaml global: user: “tidb” ssh_port: 22 deploy_dir: “/tidb-deploy” data_dir: “/tidb-data” # TiKV 全局配置 tikv: # 用 80% 内存 server.grpc-memory-pool-quota: "32GB" # 块缓存 storage.block-cache.capacity: "24GB" # Raft Engine 放在独立盘（方案 B）或者 LVM 卷上 raft-engine.dir: "/tidb-data/raft-engine…

第一个可能是 region合并卡主 第两个可能是RocksDB Tombstone堆积 按照优先级操作： 先关 Merge：pd-ctl config set max-merge-region-size 0（立即生效，风险最低） 检查 Region 状态：确认是否有 Region 卡在 pending_merge_state 检查 RocksDB tombstone：如果有大量 tombstone，考虑手动 compaction 确认索引：如果表本身没有合适的索引，limit 1 的确会走全表扫描，但即使如此，如果所有 Region 都正常，limit 1 不应超时