大家好，我司最近要是用tidb，但是还是要求对大表标进行分表（过亿行数据），顾虑如下：
1、TIDB单表也不建议超过200G存储空间。TIDB提供了分片存储，但是查询和插入效率并没有手动分表效率高。
2、TIDB单表 200G内是高效使用 超过500G就有存储风险了
3、表太大，建索引会很麻烦
请问还要分表吗，如果都用了tidb，还要分表，为什么我还要用tidb？，或者有没有什么别的处理方式
1 个赞
分表需要改造业务，业务逻辑不用动，优先建议是tidb分区。
1 个赞
查询效率还好吧，除非你都是全表扫，TP 的 SQL 用好索引效率还好啊，插入效率还行吧，没听说表大插入慢太多的
这是从哪听说的，有什么依据吗
你用过 TiDB 吗，TiDB 都是在线 DDL ，建索引不锁表，不影响 DML 的，并且高版本建索引已经较低版本提升 N 倍了
2 个赞
单表1500亿行记录高并发查询都没问题，你这个限制是听谁说的。
2 个赞
1 这个问题是 sql 本身写的有问题吧，或者时间计算的不对。你分表之后，如果不能准确的定位到某少数表的话，还是需要每个表都查询加数据整合，只是把时间和逻辑从数据库移到了应用而已
2 这个有啥风险呀？从理论上来讲不应该存在这个问题
3 这个用了新的 ingest 模式加索引能快很多，但对磁盘的空间有要求。而且分表还是那个问题，加索引还是要对每张分的表都做一遍的。
我觉得也是啊
我觉得也是，都分布式数据库了，还让我分表，我直接用mysql不行吗
分布式数据库就是为了解决单表过大导致的性能问题的，没必要在分表
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/