当我从具有标识,主键和排序键的一个表中选择具有其自己的标识集(primary,sort)的另一个表时,我最初遇到了这个问题。它没有遵守它所定义的(1,1)身份,而是(1,8)(有时候是3,8)。我想这可能是因为原始表被排序了?在试图弄清楚发生了什么时,我做了一个更简单的查询和数据,并在多个红移集群中找到了可重现的示例。以此测试为例:
drop table if exists test;
create temp table test (id int identity(1,1) not null
, value varchar(16)
, primary key (id))
diststyle all
sortkey (id);
insert into test (value) select 'a';
insert into test (value) select 'b';
insert into test (value) select 'c' union select 'd';
insert into test (value) values ('e'), ('f'), ('g');
select * from test;
我得到的输出是:
id value
1 a
2 b
9 c
10 d
3 e
4 f
5 g
您会注意到标识列未正确递增。我在其他集群上有朋友尝试这个,他们得到20,27和65,60为c和d列,而其他列是有序的。请注意,输出仍然是"排序"正确地,通过输入的排序键/顺序,尽管id列不是物理上有序的。
我在第一次发现这个和测试查询时得到的奇怪的原始结果之间唯一的相似之处就是联合被排序并且我的表上有一个排序键。
其他想法为什么会发生这种情况以及如何解决这个问题。
答案 0 :(得分:4)
不保证Redshift标识列是标识跳过值定义的增量。但是,保证值永远不会发生碰撞(即它永远是唯一的)。
跳过价值是因为Redshift的分布式架构。每个节点在数字行上保留一些值(n mod x,其中x是集群中的节点数)。因此,如果所有节点都没有获得相同数量的行,您将看到跳过标识值。