SELECT语句报"[table:1526]Table has no partition for value from column_list"

这个错误一般是指要插入的数据,发现分区键不在现有的partition范围内。理论上插入没有报错的话,select时候不该报错的。(查询语句是一个多表join的大SQL,涉及到3个分区表,还不清楚是哪个分区表导致的。。)

[table:1526]Table has no partition for value from column_list
github.com/pingcap/errors.AddStack
	/go/pkg/mod/github.com/pingcap/errors@v0.11.5-0.20211224045212-9687c2b0f87c/errors.go:174
github.com/pingcap/errors.(*Error).GenWithStackByArgs
	/go/pkg/mod/github.com/pingcap/errors@v0.11.5-0.20211224045212-9687c2b0f87c/normalize.go:164
github.com/pingcap/tidb/table/tables.(*partitionedTable).locateRangeColumnPartition
	/home/jenkins/agent/workspace/build-common/go/src/github.com/pingcap/tidb/table/tables/partition.go:1029
github.com/pingcap/tidb/table/tables.(*partitionedTable).locatePartition
	/home/jenkins/agent/workspace/build-common/go/src/github.com/pingcap/tidb/table/tables/partition.go:976
github.com/pingcap/tidb/table/tables.(*partitionedTable).GetPartitionByRow
	/home/jenkins/agent/workspace/build-common/go/src/github.com/pingcap/tidb/table/tables/partition.go:1147
github.com/pingcap/tidb/executor.(*dataReaderBuilder).buildTableReaderForIndexJoin
	/home/jenkins/agent/workspace/build-common/go/src/github.com/pingcap/tidb/executor/builder.go:4025
github.com/pingcap/tidb/executor.(*dataReaderBuilder).buildExecutorForIndexJoinInternal
	/home/jenkins/agent/workspace/build-common/go/src/github.com/pingcap/tidb/executor/builder.go:3924
github.com/pingcap/tidb/executor.(*dataReaderBuilder).buildExecutorForIndexJoin
	/home/jenkins/agent/workspace/build-common/go/src/github.com/pingcap/tidb/executor/builder.go:3917
github.com/pingcap/tidb/executor.(*innerWorker).fetchInnerResults
	/home/jenkins/agent/workspace/build-common/go/src/github.com/pingcap/tidb/executor/index_lookup_join.go:685
github.com/pingcap/tidb/executor.(*innerWorker).handleTask
	/home/jenkins/agent/workspace/build-common/go/src/github.com/pingcap/tidb/executor/index_lookup_join.go:524
github.com/pingcap/tidb/executor.(*innerWorker).run
	/home/jenkins/agent/workspace/build-common/go/src/github.com/pingcap/tidb/executor/index_lookup_join.go:498
runtime.goexit
	/usr/local/go/src/runtime/asm_amd64.s:1571

我怀疑是有脏数据导致的,因为其中一个表的分区表中存在两条数据写入到9999-12-31这个分区了,后来跟业务沟通后,把两条脏数据备份后删除了,可能是其他表还有这两条数据的关联数据没删除干净,我正在找业务确认中。
不过,理论上即便有这种数据,在select时候也不该报错。。

删除了关联的脏数据,查询还是同样报错。可以找到是哪个表的partition的查询有问题么?[table:1526]这个指的是表id么?information_schema.tables没有找到是哪个表

你的是什么版本 ?有类似这种issue。

https://github.com/pingcap/tidb/issues/31523

1 个赞

是6.1.2,我的场景和这个还不一样,是纯粹多表join的select,没有加for update

对涉及到分区表都加上了个兜底的pfuture分区,问题解决了。感觉是扫描的中间数据有不自洽的,导致扫描到其他表时候,使用的分区键可能超过了原始表的限制(其实完全可以把这些数据直接当成没有匹配到处理,反正原始表肯定没这些数据)。执行的添加兜底分区的SQL为:

alter table test.t1 ADD PARTITION (PARTITION pfuture VALUES LESS THAN (MAXVALUE));

PS: 由于TiDB 6.1还不支持REORGANIZE PARTITION操作,所以为了能定时续建分区,只创建了下一年的分区,并没有创建兜底的pfuture分区

您好,请问添加 pfuture 分区以后,报错就绕过去了吗?能否提供一下复现步骤,我们试试重现一下,看看以后能不能产品修复。