TiDB按日期分区的最佳方案

[qihuajun]

为提高效率，提问时请提供以下信息，问题描述清晰可优先响应。

• 【TiDB 版本】：3.0.9
• 【问题描述】：我们有一个表数据是按日期存放的，主要的查询也是按日期查询，每个date的数据量大概有100多万，我想把这张表按照date字段分区（每天一个分区），请问：

1. 每日一个分区是否可行，我们会存放几年的数据，TiDB对于分区数是否有限制？
2. 如果根据date字段设置每日一个分区只能手动设置range分区吗？有没有更方便的按日期分区的方式？
3. 如果我们按照date字段每日一个分区存储，那相邻日期的数据是连续的吗？我如果读一段时间段的数据会慢吗？
4. hash分区是否支持分区裁剪？
5. between查询，>,<,>=,<=的范围查询是否支持分区裁剪？

若提问为性能优化、故障排查类问题，请下载脚本运行。终端输出的打印结果，请务必全选并复制粘贴上传。

[yilong (yi888long)]

您好： 预格式化文本

1. 每日一个分区是否可行，我们会存放几年的数据，TiDB对于分区数是否有限制？ — >不限制
2. 如果根据date字段设置每日一个分区只能手动设置range分区吗？有没有更方便的按日期分区的方式？ —>需要手动设置
3. 如果我们按照date字段每日一个分区存储，那相邻日期的数据是连续的吗？我如果读一段时间段的数据会慢吗？ —> 一个分区本质上可以看作一张表，它在存储层有新的 table id，所以分区之间不保证连续
4. hash分区是否支持分区裁剪？ —> 支持，但是多列最好不要使用
5. between查询，>,<,>=,<=的范围查询是否支持分区裁剪？ —>range分区支持，hash不支持

请参考文档中的一些介绍 https://pingcap.com/docs-cn/stable/reference/sql/partitioning/#分区表

[qihuajun]

谢谢回复！

如果我按照月来做分区，每个月的数据大概3000W~5000W，100G左右，那对于读写的性能会有影响吗？TiDB底层本身还有region的概念，那是不是单表很大的情况下性能下降也不会很厉害？

[yilong (yi888long)]

如果不是列数非常多的宽表几百列，一个月3000w-5000w应该没有什么问题的， 当前有些分区表好像一天应该就有1亿的数据了.

[qihuajun]

好的，那应该问题不大，我们的表最多的也就20多列。

谢谢！

[yilong (yi888long)]

[heaven_touch (heaven)]

4.0.2 版本添加分区时报错 ERROR 1499: too many partitions were defined
是有限制分区数吗

[sunlide]

@heaven_touch

4.0.2

4.0.3支持动态增加分区。
– 添加分区
ALTER TABLE sms_sendlog
ADD PARTITION (
PARTITION p20201101 VALUES LESS THAN ( UNIX_TIMESTAMP(‘2020-11-01 00:00:00’) ),
PARTITION p20201102 VALUES LESS THAN ( UNIX_TIMESTAMP(‘2020-11-02 00:00:00’) ),
PARTITION p20201103 VALUES LESS THAN ( UNIX_TIMESTAMP(‘2020-11-03 00:00:00’) ),
PARTITION p20201104 VALUES LESS THAN ( UNIX_TIMESTAMP(‘2020-11-04 00:00:00’) ),
PARTITION p20201105 VALUES LESS THAN ( UNIX_TIMESTAMP(‘2020-11-05 00:00:00’) ),
PARTITION p20201106 VALUES LESS THAN ( UNIX_TIMESTAMP(‘2020-11-06 00:00:00’) ),
PARTITION p20201107 VALUES LESS THAN ( UNIX_TIMESTAMP(‘2020-11-07 00:00:00’) ),
PARTITION p20201108 VALUES LESS THAN ( UNIX_TIMESTAMP(‘2020-11-08 00:00:00’) ),
PARTITION p20201109 VALUES LESS THAN ( UNIX_TIMESTAMP(‘2020-11-09 00:00:00’) ),
PARTITION p20201110 VALUES LESS THAN ( UNIX_TIMESTAMP(‘2020-11-10 00:00:00’) ),
PARTITION p20201111 VALUES LESS THAN ( UNIX_TIMESTAMP(‘2020-11-11 00:00:00’) ),
PARTITION p20201112 VALUES LESS THAN ( UNIX_TIMESTAMP(‘2020-11-12 00:00:00’) ),
PARTITION p20201113 VALUES LESS THAN ( UNIX_TIMESTAMP(‘2020-11-13 00:00:00’) ),
PARTITION p20201114 VALUES LESS THAN ( UNIX_TIMESTAMP(‘2020-11-14 00:00:00’) ),
PARTITION p20201115 VALUES LESS THAN ( UNIX_TIMESTAMP(‘2020-11-15 00:00:00’) ),
PARTITION p20201116 VALUES LESS THAN ( UNIX_TIMESTAMP(‘2020-11-16 00:00:00’) ),
PARTITION p20201117 VALUES LESS THAN ( UNIX_TIMESTAMP(‘2020-11-17 00:00:00’) ),
PARTITION p20201118 VALUES LESS THAN ( UNIX_TIMESTAMP(‘2020-11-18 00:00:00’) ),
PARTITION p20201119 VALUES LESS THAN ( UNIX_TIMESTAMP(‘2020-11-19 00:00:00’) ),
PARTITION p20201120 VALUES LESS THAN ( UNIX_TIMESTAMP(‘2020-11-20 00:00:00’) ),
PARTITION p20201121 VALUES LESS THAN ( UNIX_TIMESTAMP(‘2020-11-21 00:00:00’) ),
PARTITION p20201122 VALUES LESS THAN ( UNIX_TIMESTAMP(‘2020-11-22 00:00:00’) ),
PARTITION p20201123 VALUES LESS THAN ( UNIX_TIMESTAMP(‘2020-11-23 00:00:00’) ),
PARTITION p20201124 VALUES LESS THAN ( UNIX_TIMESTAMP(‘2020-11-24 00:00:00’) ),
PARTITION p20201125 VALUES LESS THAN ( UNIX_TIMESTAMP(‘2020-11-25 00:00:00’) ),
PARTITION p20201126 VALUES LESS THAN ( UNIX_TIMESTAMP(‘2020-11-26 00:00:00’) ),
PARTITION p20201127 VALUES LESS THAN ( UNIX_TIMESTAMP(‘2020-11-27 00:00:00’) ),
PARTITION p20201128 VALUES LESS THAN ( UNIX_TIMESTAMP(‘2020-11-28 00:00:00’) ),
PARTITION p20201129 VALUES LESS THAN ( UNIX_TIMESTAMP(‘2020-11-29 00:00:00’) ),
PARTITION p20201130 VALUES LESS THAN ( UNIX_TIMESTAMP(‘2020-11-30 00:00:00’) )
);
线上可行

[qihuajun]

谢谢！

[GangShen]