【有哪些好的运维习惯/创新实践，帮你兜住了哪些风险？】
gc时间调长，挽救误操作，全量增量备份兜底。
【用了 TiDB 是否让你更省心？】
安装部署简单，运维简单，监控全排查问题方便。
你配置改错地方了啊， TiCDC Changefeed 配置文件是指启动任务的时候制定的–config 文件 不是cdc本身的配置。
不是让你看/app/tidbsoft/cdc-8300/log 这个日志麻 发出来看看
你的版本太老了 4.0版本的ticdc那时候问题挺多的
这种好查，在topsql里看下是哪些sql引起的，看下执行计划，大概率有全表扫描的sql。
看你需求啊，核心数据库对性能有要求，肯定要考虑磁盘性能的。
你这集中式存储设备用肯定能用的，但是性能堪忧，有很大概率多个kv数据节点会存储在同一个磁盘上。
你慢sql按照总执行时间排序看下 没有那条慢sql吗？
一个是单条sql耗时，一个是一段时间内同类sql的平均耗时，当然不一样
如果查询带上分区键确实会快一点，如果没有反而会变很慢。看你们分区表怎么使用的，大部分人分区表都是用来删除指定分区数据的。
你都设置分区了，还用ttl干嘛？分区的唯一作用就是删除数据非常快
你所在企业是否有出海规划或已开展出海业务？企业出海的核心目标区域 / 国家是哪里？
有，主要是东南亚
驱动企业出海的核心因素是什么（如市场扩张、政策支持等）？
市场
出海场景下，你最关注数据库的哪些能力（如合规适配、跨区域部署、低运维等）？最关注的技术问题是什么？
出海和用什么数据库没有关联
出海场景下，你更倾向选择自建数据库还是全托管数据库服务？
看经费
出海业务中，你会选择 TiDB 吗？
看系统架构。
tiKV 默认的磁盘保护阈值通过 low-space-ratio参数控制,超过这个值就写入不了数据了
![[image]](https://asktug.com/uploads/default/original/4X/8/9/2/89213e8d61eafba1796837e7a033ca5c6a41b978.png){kind=link}