TiDB还用不用分表,或者说在什么情况下要分表

大家好,我司最近要是用tidb,但是还是要求对大表标进行分表(过亿行数据),顾虑如下:
1、TIDB单表也不建议超过200G存储空间。TIDB提供了分片存储,但是查询和插入效率并没有手动分表效率高。
2、TIDB单表 200G内是高效使用 超过500G就有存储风险了
3、表太大,建索引会很麻烦
请问还要分表吗,如果都用了tidb,还要分表,为什么我还要用tidb?,或者有没有什么别的处理方式

1 个赞

分表需要改造业务,业务逻辑不用动,优先建议是tidb分区。

1 个赞

查询效率还好吧,除非你都是全表扫,TP 的 SQL 用好索引效率还好啊,插入效率还行吧,没听说表大插入慢太多的

这是从哪听说的,有什么依据吗

你用过 TiDB 吗,TiDB 都是在线 DDL ,建索引不锁表,不影响 DML 的,并且高版本建索引已经较低版本提升 N 倍了

2 个赞

单表1500亿行记录高并发查询都没问题,你这个限制是听谁说的。
image

2 个赞

1 这个问题是 sql 本身写的有问题吧,或者时间计算的不对。你分表之后,如果不能准确的定位到某少数表的话,还是需要每个表都查询加数据整合,只是把时间和逻辑从数据库移到了应用而已
2 这个有啥风险呀?从理论上来讲不应该存在这个问题
3 这个用了新的 ingest 模式加索引能快很多,但对磁盘的空间有要求。而且分表还是那个问题,加索引还是要对每张分的表都做一遍的。

我觉得也是啊

我觉得也是,都分布式数据库了,还让我分表,我直接用mysql不行吗

分布式数据库就是为了解决单表过大导致的性能问题的,没必要在分表

1 个赞

:thinking:这个应该取决业务和硬件吧,本身分库分表是在资源不足情况下一种妥协的解决方案

1 个赞

除非业务设计有问题,一般来说不用分表。
分区也是删除数据比较方便,其他并没有优势。

用分区表吧。

1 个赞

都可以吧,分表总有些索引使用不太好的语句

如果分表过多,后期维护比较麻烦。用分区表会更好点

提到的这3个场景都是 TiDB 的舒适圈 放心用起来~

直接利用 TiDB 的原生能力即可满足处理过亿行记录的需求,无需手动分表。

1,tidb serverless云服务上,还有单表600T的业务在支撑。不建议超过200g,从何说起?tidb的读写能力和节点数量有关,如果节点数量不够,别说200g,20g可能也很慢。读写能力是根据你的资源配置线性扩展的,没有硬性标准说大于多少就不行。

2,同上。你要机器不行,多要资源吧。tidb不背这个锅。

3,这在7.5版本以前确实是个问题。只有ddl owner一个节点在工作,大表加索引是个痛点。

7.5版本之后,有分布式执行框架,可以多找几台tidb节点,并行加索引,大表加索引慢的问题,也变成了和你的资源配置线性相关了。

https://docs.pingcap.com/zh/tidb/stable/tidb-distributed-execution-framework/