分区表性能稍差一些
你的业务可以用分区表，例如增加年月字段，里面写上当时的年月，然后按这个字段分区，需要清理数据，直接truncate对应分区即可，但是tidb的分区表bug确实有。
你测试好就可以用，用了变快变慢都有可能
不止这个，我们原来有个oracle表，联合字段主键，还有想加个自增列，然后分区键 tidb要求上面的都要放主键，然后唯一约束就没了
确实，深有同感。不过还是取决于sql的好坏。
这个是实话，我们使用的6.5.4版本，分区表统计信息收集有问题，一直也被吐槽的比较多，有些时候使用分区表执行计划走偏的原因就是分区表的自动统计信息收集收集不及时或者过期导致的。
（1）我们目前都是需要频繁删除或者需要进行生命周期管理的数据就使用分区表，比如需要存储最近一年的交易流水数据，超过一年的就自动删除，这种就挺适合用分区表的truncate partition的方式每天删除一次一年前的分区数据，如果不采用的话，就只能采用拆批的形式进行删除，这种方式效率说实话一般，而且这种操作多了对集群影响也大，对集群资源也有点浪费。
（2）对于查询的话，我们是采用冷热数据分离的形式，分两张表，冷数据（如历史数据）放在分区表里，热数据则放在当前表里。
（3）还有一个统计信息收集问题，如果分区表的统计信息收集达不到要求，有需要考虑下通过脚本定时对统计信息过期的分区进行统计信息收集。
这两个也算一个比较大的提升，对于导入数据到新分区里，分区信息统计信息收集不及时的问题不知道有没有修复，我们之前出现比较多的是通过Lightning导入数据到分区表里有的分区统计信息收集成功，有的分区统计信息没有收集成功。
这两个应该在7.5.1已经修复了。
这个大概率是执行analyze时候超时报错了，tidb-lightning是物理导入结束后，手动执行一下analyze table的操作，如果执行超时后，并不会自动重试。
这种情况没有分区表就很不好清理。还是建议使用分区表的。
1 个赞
不适合
用呗，好处比坏处多
历史旧数据归档就可以了，不要用分区表！！！
TiDB 适合使用分区表，特别是在处理大量数据或者需要按照时间范围等条件进行数据分割和管理的情况下，分区表可以带来一些性能和管理上的优势。以下是一些关于在 TiDB 中使用分区表的优势和考虑因素：
- 性能优势：
- 查询性能：当表数据量大时，使用分区表可以将数据分布到不同的分区中，减少单个分区的数据量，提高查询性能。
- 分区裁剪：在查询时，TiDB 可以根据分区键的范围进行分区裁剪，只查询符合条件的分区，减少扫描的数据量，进而提高查询效率。
- 数据管理优势：
- 数据维护：使用分区表可以更方便地管理数据，例如根据时间范围创建新的分区、删除过期数据等。
- 备份与恢复：对分区表进行备份和恢复时，可以针对单个分区进行操作，提高备份恢复效率。
- 数据调度优势：
- 数据加载：在数据导入时，可以根据分区键将数据直接导入到对应的分区中，减少数据移动和调整的开销。
- 数据清理：针对历史数据的清理和归档也更加方便，可以根据分区进行数据删除操作。
需要注意的是，在设计分区表时，需要合理选择分区键，通常选择一个经常用于查询和过滤的列作为分区键，以充分利用分区裁剪的性能优势。此外，在使用分区表时，还需要考虑分区数量的设置、分区键的选择、分区间数据均衡等因素，以达到最佳的性能和管理效果。
2 个赞
tidb不就是解决了分库分表的问题吗？
1 个赞
不，是分区表统计信息收集本身就有问题，我们不只是有通过Lightning导入的分区表，还有其他没有使用Lightning导入的分区表，而且我们采用的并不是local模式，而是tidb模式。