【TiDB 使用环境】生产环境
【TiDB 版本】v6.5.5
【操作系统】CentOS
【部署方式】机器部署 3台32C、64G内存2T硬盘
【集群节点数】3
我有一个时序数据的大表，是从Clickhouse迁移过来的，每天的数据量在千万到亿级别，目前就在一个大表里面，本来计划是重新搞到分区表里面，按时间字段使用range分区，但测试以下发现查询时索引似乎也是分区的，每次查询还得先确定是哪个分区，不指定分区的话查询就会卡死，很多简单的查询，比如总行数都需要指定分区，使用很不方便，请教一下大家有什么好的使用经验
tidb没必要分区，查询的字段加索引就行
你导入完之后 ANALYZE TABLE 了吗？我们有一个十亿级别的表，修改为分区表后，也遇到了类似的问题，ANALYZE TABLE 后就好了。
如果无法从条件推断出数据在哪些分区，那就需要指定分区，否则是需要全表的
贴下卡死的sql执行计划看下
我们有张100亿的表。。不过不是核心表。。保留6个月。
目前确实是按不分区使用，不过索引已经几百G了，主要是担心以后会不会出问题
sql where条件中有分区字段，但是执行计划就全表扫描了，分区字段还有索引也没有使用
像Clickhouse里面分区之后基本上SQL条件里面有分区键自动就使用正确的分区了，Tidb似乎这方面优化不够，大家有什么好的实践经验吗？
针对 TiDB v6.5.5 生产环境下 百亿级时序大表的分区存储方案，结合你的核心痛点（不指定分区查询卡死、日常操作不便），可从 分区设计优化、索引策略调整、分区剪枝保障、查询习惯适配、集群参数调优 五个维度系统性解决
表结构、查询语句和执行计划放上来看看
放弃range分区表，改用“按时间分表+业务层路由”架构，并启用tiflash加速聚合查询，是应对亿级时序数据在生产环境最稳定高效的方案。
我也建议按时间分表加业务层路由。仅仅日志表或者滚动表才会考虑分区表