版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/sunlen/article/details/102969851
在使用Phoenix的过程中，发现了一个奇怪的异常现象，其中一个表，有个字段（VARCHAR类型），一旦这个字段被更新为null值，从此就无法重新更新该字段的值。
我在测试过程中，重新新建一张表，就发现可以正常更新，是我困惑不已。
最后经过反复对比，发现是另外一个字段设置成ROW_TIMESTAMP导致的，下面详细讲述一些问题的复习。
目前测试发现问题的Phoenix版本为4.14.0，另外，我在阿里云的5.2.0版本上测试，也同样发现该问题。
先来讲一下正常的逻辑情况。
首先我们先建立一个测试表，语句如下：
CREATE TABLE hyy_test_1(
f_index CHAR(2) not null,
f_create_time date not null,
f_content VARCHAR,
constraint pk primary key(f_index, f_create_time)
)
SALT_BUCKETS = 20;
注意一下，这里的f_create_time是主键，但没有设置为ROW_TIMESTAMP类型，f_content就是我们要测试的VARCHAR字段。
接下来，我们往该表加一条有值的数据，语句如下：
upsert into hyy_test_1(f_index, f_create_time, f_content) values('1', '2019-11-07 14:01:37','哈哈哈');
查询表数据，发现数据正常插入：
接下来重新把f_content赋值为null，发现正常更新：
接下来重新给f_content赋值为非null的值，发现也正常更新了：
到这里，说明数据的更新完全正常，下面我们稍微修改一个表结构，将f_create_time修改为ROW_TIMESTAMP类型，建表语句如下：
CREATE TABLE hyy_test_2(
f_index CHAR(2) not null,
f_create_time date not null,
f_content VARCHAR,
constraint pk primary key(f_index, f_create_time ROW_TIMESTAMP)
)
SALT_BUCKETS = 20;
给表新增一条f_content为空的数据，可以正常新增：
将f_content更新为null，数据可以正常更新：
重新将f_content更新为非空数据，神奇的现象出现了，数据无法更新：
由此可以看出，因为ROW_TIMESTAMP的原因，导致了该问题，目前Phoenix对ROW_TIMESTAMP实现不是太好，里面坑很多。而且，实际上，这个实现作用并不大，很容易就可以替换掉，建议不要使用该方式。
