数据量达到多少（多少条数据，占用多少存储空间）开始使用分区表
1 个赞
Tidb底层会自动分片，你说的分区表，应该是业务层根据业务需求自定义的，这没有一个标准，全看你业务规划。
1 个赞
一、常规业务表（OLTP 主业务表）
- 数据条数参考：单表数据量超过 1 亿条，且后续仍有持续增长趋势时，可考虑分区表。
- 存储大小参考：单表实际占用存储空间超过 100GB，且查询 / 维护性能出现明显衰减时，可考虑分区表。
二、时间序列类表（日志、流水、审计、监控数据）
- 数据条数参考：单表数据量超过 5000 万条，且查询条件固定带时间范围过滤时，建议使用分区表。
- 存储大小参考：单表实际占用存储空间超过 50GB，且需要按月 / 按天批量清理或归档数据时，建议使用分区表。
三、冷热分离类表（需定期清理 / 归档历史数据）
- 数据条数参考：无固定条数阈值，只要业务存在按时间批量删除、归档的需求，无论数据量多少，都建议使用分区表（避免 DELETE 全表扫描）。
- 存储大小参考：单表冷数据占比超过 50%，且需要将冷数据分离到低成本存储介质时，建议使用分区表。
参考一下吧
1 个赞
没有统一标准的，需要看业务规划
这个主要看业务性质和业务数据量情况吗
这个一般都是看业务的需求规划的
我们目前实践超过1000万的才会考虑
除非有用删除分区方式快速清理历史数据需求，否则不要用分区表
1 个赞
为什么呀？分区表不是可以提升查询性能吗？
目前没有用到分区，这个应该跟业务，还有设备有关吧
用TiDB的初衷就是不用分区分表分库。
使用分区表要考虑行数和表大小，太小的不建议使用
不分区，历史数据归档或者清理不太方便吧
是否使用分区，不能简单以数据量大小为判断。比如 按时间快速归档/删除大量历史数据的场景可以使用分区表
说得对
过滤条件不带分区键查询时，会变成分别在所有分区执行完在merge，这个效率很差
还有其他就是，分区表收集统计信息有概率ｈａｎｇ住
这个感觉是一个偏业务的问题，没有标准，这边是数据量超过300万的考虑分区表
分区表不能提高查询性能，根据我得经验，执行计划出错概率反而变大了。从底层看，tikv你可以理解是表id+主键有序kv序列，分区表每个分区有个表id，其实并没实质区别
另外分区表查询，需要你where条件都带上分区键值，你的主键也必须加分区键值，统计收集会慢很多而且容易报错，出现执行计划偏差
tidb归档最快方式是dumpling导出，再导入到一个库里，直接操作原库归档都很慢