只能说 小伙子，你的想法很危险

以前的业务用的oracle，有外键，数据维护的时候，恶心的一批

以前在oracle中，我一般是根据表数量预估，查询统计信息表（视图）中的更新时间在开始执行统计信息收集之后的占比。 当然还可以根据数据量进行预估，就是把上面查到的表，在拿去统计所占的数据量。 我想tidb应该也可以用这样的思路去预估。

生产环境必须主备双集群，上双保险

盲猜是内存的问题，局域网内的带宽不至于支撑不住。

分库分表维护成本太高

搞反了啊 老兄，先扩在缩

从经验来看，首先是排查慢sql问题

是不是数据量太大了

必须选B呀

1、做好监控； 2、数据变更前，做好备份或者准备好回滚脚本； 3、出了问题第一时间报告，准备证据找人背锅； 4、找不到人背锅就只有自己背。

这个情况只有进行业务管理了，要么必须有主键或者唯一索引，要么就不保证数据同的强一致性。

曲线救国，先导入到一张空表，再insert into到空表里面，如果数据量大，可以考虑分批次提交，问题不大

参考文档资料，横向扩容即可，想扩什么扩什么

很正常的吧，一个是统计服务，一个是统计服务器。

dc host rack 需要在pd设置中进行 replication.location-labels配置

奇怪了，难道是BUG或者是理解不对吗

iostat -x 30 看最后一列，能看出磁盘的实际繁忙程度

跟数据量和索引都有关系吧