没什么影响，我们这个集群每天的写入量是很大的，类似物联网那种数据会很多。之前为了做灾备集群同步数据临时改成过5天，也没有明显的延迟

我们这个集群40多TB，每天写入量不少，设置的是2天（防止周末有人误操作了周一还能快速回滚），目前没发现有明显性能问题，不过不建议设置的太大了，不然磁盘也是个问题。

3PC需要更多的通讯次数，实现比较复杂。大多数使用一致性提交协议的系统都采用二阶段提交协议。

5个节点宕机一个是没问题的，同时宕机2个就不行了

多表拆成多个drainer任务会有性能提升的，我们是一个大表单独一个任务

主键不是数字的可以用隐藏字段_tidb_rowid

没区别，现在只是语法上兼容，实际还不支持 [image]

看看是否设置了这个参数MAX_EXECUTION_TIME

tidb本身有gc，gc时间内的数据都可以恢复，不需要延迟备库 https://docs.pingcap.com/zh/tidb/stable/garbage-collection-overview/

【大家所在的行业是什么？】 能源 【所在行业对数据库容灾有哪些具体需求？】 应用级别1:1异地灾备 【目前正在采用的容灾方案是什么？】 ticdc同步

看下leader分布，是不是这个节点重启过，leader都切到其他节点了

【你想使用的数据库是什么样的】 高可用，自动拓展 【在哪些方面你会给 TiDB 投一票？易用性 or 其他？】 易用性

一个tikv里有n多个region，tikv本身没有leader的概念，一般情况下都是在工作的

pd可以通过tiup cluster display看哪个是leader，tidb节点是无状态的，tikv也不分leader、follower、learner，region才分这些。

【你在毕业前学的是什么专业或研究方向】 软件工程 【如果时光倒流，如果你还想从事数据库相关工作，你会选择读什么专业】 软件工程 【现在还是学习、从事计算机（数据库）行业的好年代么】 不是很建议新人入行 【其他想分享的话】 大学一定要规划好以后要做什么，早打基础。

/*+read_from_storage(tiflash[middleground.m])*/ 显式地指定数据库名试试

1.text字段建议单独放一个表关联查询 2.select建议只查需要的字段，当然主要开销还是看过where条件滤数的据量大小和有没有索引 3.要不要使用tiflash要看具体SQL，比如大数据量的聚合之类的比较适合，并发不能太高，需要实际跑一下看看是否有效率提升 最好还是具体SQL具体对待，把实际SQL发出来看看

直接tiup部署很快，或者tiup playground部署个测试环境玩玩一个命令几分钟就能部署好 https://docs.pingcap.com/zh/tidb/stable/quick-start-with-dm/#第-1-步搭建测试环境

不太建议用swap，磁盘是固态吗，另外3台混部资源确实紧张了，和我这边的测试集群配置差不多，也就跑跑功能测试，做不了压测。