数据更新

利用查询引擎自身的 where 过滤逻辑，从待更新表中筛选出需要被更新的行。再利用 Unique 模型自带的 Value 列新数据替换旧数据的逻辑，将待更新的行变更后，再重新插入到表中，从而实现行级别更新。

Update 语法在Doris中是一个同步语法，即 Update 语句执行成功，更新操作也就完成了，数据是可见的。

Update 语句的性能和待更新的行数以及 condition 的检索效率密切相关。

待更新的行数：待更新的行数越多，Update 语句的速度就会越慢。这和导入的原理是一致的。 Doris 的更新比较合适偶发更新的场景，比如修改个别行的值。 Doris 并不适合大批量的修改数据。大批量修改会使得 Update 语句运行时间很久。
condition 的检索效率：Doris 的 Update 实现原理是先将满足 condition 的行读取处理，所以如果 condition 的检索效率高，则 Update 的速度也会快。 condition 列最好能命中索引或者分区分桶裁剪，这样 Doris 就不需要扫全表，可以快速定位到需要更新的行，从而提升更新效率。 强烈不推荐 condition 列中包含 UNIQUE 模型的 value 列。

默认情况下，并不允许同一时间对同一张表并发进行多个 Update 操作。

主要原因是，Doris 目前支持的是行更新，这意味着，即使用户声明的是，实际上，其他所有的 Value 列也会被覆盖一遍（尽管值没有变化）。

但在实际应用中，如果用户自己可以保证即使并发更新，也不会同时对同一行进行操作的话，就可以手动打开并发限制。通过修改 FE 配置，当配置值为 true 时，则对更新并发无限制。

由于 Doris 目前支持的是行更新，并且采用的是读取后再写入的两步操作，则如果 Update 语句和其他导入或 Delete 语句刚好修改的是同一行时，存在不确定的数据结果。

所以用户在使用的时候，一定要注意用户侧自己进行 Update 语句和其他 DML 语句的并发控制。

假设 Doris 中存在一张订单表，其中订单id 是 Key 列，订单状态，订单金额是 Value 列。数据状态如下：

这时候，用户点击付款后，Doris 系统需要将订单id 为 ‘1’ 的订单状态变更为 ‘待发货’，就需要用到 Update 功能。

用户执行 UPDATE 命令后，系统会进行如下三步：

由于表 test_order 是 UNIQUE 模型，所以相同 Key 的行，之后后者才会生效，所以最终效果如下：