This is an automated email from the ASF dual-hosted git repository.

dataroaring pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/doris-website.git


The following commit(s) were added to refs/heads/master by this push:
     new 041b807a501 [fix](update) add missing part in chinese for 3.x and 4.x 
(#3237)
041b807a501 is described below

commit 041b807a501b9834b7e309aaba64508743b421ea
Author: Yongqiang YANG <[email protected]>
AuthorDate: Mon Dec 29 19:39:20 2025 -0800

    [fix](update) add missing part in chinese for 3.x and 4.x (#3237)
    
    ## Versions
    
    - [ ] dev
    - [x] 4.x
    - [x] 3.x
    - [ ] 2.1
    
    ## Languages
    
    - [ ] Chinese
    - [ ] English
    
    ## Docs Checklist
    
    - [ ] Checked by AI
    - [ ] Test Cases Built
---
 .../data-operate/update/unique-update-sql.md       | 123 ++++++
 .../data-operate/update/update-of-unique-model.md  |   3 +-
 .../current/data-operate/update/update-overview.md |   4 +-
 .../data-operate/update/partial-column-update.md}  | 227 ++++-------
 .../data-operate/update/unique-update-sql.md       | 123 ++++++
 .../update/update-of-aggregate-model.md            |  50 +--
 .../data-operate/update/update-of-unique-model.md  | 377 +----------------
 .../data-operate/update/update-overview.md         |   4 +-
 ...of-unique-model.md => partial-column-update.md} | 227 ++++-------
 .../data-operate/update/unique-update-sql.md       | 123 ++++++
 .../update/update-of-aggregate-model.md            |  50 +--
 .../data-operate/update/update-of-unique-model.md  | 444 +--------------------
 .../data-operate/update/update-overview.md         |   4 +-
 .../images/update-overview/update-by-loading.png   | Bin 519541 -> 323906 bytes
 static/images/update-overview/update-self.png      | Bin 323906 -> 519541 bytes
 15 files changed, 540 insertions(+), 1219 deletions(-)

diff --git 
a/i18n/zh-CN/docusaurus-plugin-content-docs/current/data-operate/update/unique-update-sql.md
 
b/i18n/zh-CN/docusaurus-plugin-content-docs/current/data-operate/update/unique-update-sql.md
new file mode 100644
index 00000000000..67ff892679e
--- /dev/null
+++ 
b/i18n/zh-CN/docusaurus-plugin-content-docs/current/data-operate/update/unique-update-sql.md
@@ -0,0 +1,123 @@
+---
+{
+    "title": "使用 UPDATE 命令更新数据",
+    "language": "zh-CN",
+    "description": "这篇文档介绍如何在 Doris 中使用 UPDATE 命令修改数据。"
+}
+---
+
+这篇文档介绍如何在 Doris 中使用 `UPDATE` 命令修改数据。`UPDATE` 命令仅适用于主键模型(Unique Key Model)表。
+
+## 适用场景
+
+- 小规模数据更新:适用于需要修正少量数据的场景,例如修正某些记录中的错误字段,或更新特定字段的状态(如订单状态更新)。
+
+- 某些字段的 ETL 批量处理:适用于对某个字段进行大规模更新的场景,常见于 ETL 处理场景。注意:大规模数据更新应该是不频繁的。
+
+## 工作原理
+
+查询引擎使用自身的过滤逻辑来识别需要更新的行。然后,使用主键模型的 Value 
列逻辑,用新数据替换旧数据。需要更新的行被修改后重新插入到表中,以实现行级更新。
+
+### 同步性
+
+Doris 中的 `UPDATE` 语法是同步的,这意味着一旦 `UPDATE` 语句成功执行,更新操作就已完成,数据立即可见。
+
+### 性能
+
+`UPDATE` 语句的性能与需要更新的行数和查询条件的效率密切相关。
+
+- 需要更新的行数:需要更新的行数越多,`UPDATE` 语句的执行速度就越慢。对于小规模更新,Doris 支持与 `INSERT INTO` 
语句相似的频率。对于大规模更新,由于执行时间较长,仅适用于不频繁的调用。
+
+- 查询条件的效率:`UPDATE` 实现首先读取满足查询条件的行。因此,如果查询条件高效,`UPDATE` 
速度就会快。理想情况下,条件列应该命中索引或分区桶裁剪,这样 Doris 
就不需要扫描整个表,可以快速定位需要更新的行,从而提高更新效率。强烈建议不要在条件列中包含值列。
+
+## 使用示例
+
+假设在金融风控场景中存在一张交易明细表,结构如下:
+
+```sql
+CREATE TABLE transaction_details (
+  transaction_id BIGINT NOT NULL,        -- 唯一交易 ID
+  user_id BIGINT NOT NULL,               -- 用户 ID
+  transaction_date DATE NOT NULL,        -- 交易日期
+  transaction_time DATETIME NOT NULL,    -- 交易时间
+  transaction_amount DECIMAL(18, 2),     -- 交易金额
+  transaction_device STRING,             -- 交易设备
+  transaction_region STRING,             -- 交易地区
+  average_daily_amount DECIMAL(18, 2),   -- 最近 3 个月的平均日交易金额
+  recent_transaction_count INT,          -- 最近 7 天的交易次数
+  has_dispute_history BOOLEAN,           -- 是否有争议历史
+  risk_level STRING                      -- 风险等级
+)
+UNIQUE KEY(transaction_id)
+DISTRIBUTED BY HASH(transaction_id) BUCKETS 16
+PROPERTIES (
+  "replication_num" = "3",               -- 副本数,默认为 3
+  "enable_unique_key_merge_on_write" = "true"  -- 启用 MOW 模式,支持合并更新
+);
+```
+
+存在以下交易数据:
+
+```sql
++----------------+---------+------------------+---------------------+--------------------+--------------------+--------------------+----------------------+--------------------------+---------------------+------------+
+| transaction_id | user_id | transaction_date | transaction_time    | 
transaction_amount | transaction_device | transaction_region | 
average_daily_amount | recent_transaction_count | has_dispute_history | 
risk_level |
++----------------+---------+------------------+---------------------+--------------------+--------------------+--------------------+----------------------+--------------------------+---------------------+------------+
+|           1001 |    5001 | 2024-11-24       | 2024-11-24 14:30:00 |          
   100.00 | iPhone 12          | New York           |               100.00 |    
                   10 |                   0 | NULL       |
+|           1002 |    5002 | 2024-11-24       | 2024-11-24 03:30:00 |          
   120.00 | iPhone 12          | New York           |               100.00 |    
                   15 |                   0 | NULL       |
+|           1003 |    5003 | 2024-11-24       | 2024-11-24 10:00:00 |          
   150.00 | Samsung S21        | Los Angeles        |               100.00 |    
                   30 |                   0 | NULL       |
+|           1004 |    5004 | 2024-11-24       | 2024-11-24 16:00:00 |          
   300.00 | MacBook Pro        | high_risk_region1  |               200.00 |    
                    5 |                   0 | NULL       |
+|           1005 |    5005 | 2024-11-24       | 2024-11-24 11:00:00 |          
  1100.00 | iPad Pro           | Chicago            |               200.00 |    
                   10 |                   0 | NULL       |
++----------------+---------+------------------+---------------------+--------------------+--------------------+--------------------+----------------------+--------------------------+---------------------+------------+
+```
+
+根据以下风控规则更新所有当日交易记录的风险等级:
+1. 有争议历史的交易风险等级为 high。
+2. 高风险地区的交易风险等级为 high。
+3. 异常金额(超过日均金额 5 倍)的交易风险等级为 high。
+4. 最近 7 天频繁交易:
+   a. 交易次数 > 50 次的交易风险等级为 high。
+   b. 交易次数在 20 到 50 次之间的交易风险等级为 medium。
+5. 非工作时间(凌晨 2 点到 4 点)的交易风险等级为 medium。
+6. 默认风险等级为 low。
+
+```sql
+UPDATE transaction_details
+SET risk_level = CASE
+  -- 有争议历史或高风险地区的交易
+  WHEN has_dispute_history = TRUE THEN 'high'
+  WHEN transaction_region IN ('high_risk_region1', 'high_risk_region2') THEN 
'high'
+
+  -- 异常交易金额
+  WHEN transaction_amount > 5 * average_daily_amount THEN 'high'
+
+  -- 最近 7 天高频交易
+  WHEN recent_transaction_count > 50 THEN 'high'
+  WHEN recent_transaction_count BETWEEN 20 AND 50 THEN 'medium'
+
+  -- 非工作时间交易
+  WHEN HOUR(transaction_time) BETWEEN 2 AND 4 THEN 'medium'
+
+  -- 默认风险等级
+  ELSE 'low'
+END
+WHERE transaction_date = '2024-11-24';
+```
+
+更新后的数据如下:
+
+```sql
++----------------+---------+------------------+---------------------+--------------------+--------------------+--------------------+----------------------+--------------------------+---------------------+------------+
+| transaction_id | user_id | transaction_date | transaction_time    | 
transaction_amount | transaction_device | transaction_region | 
average_daily_amount | recent_transaction_count | has_dispute_history | 
risk_level |
++----------------+---------+------------------+---------------------+--------------------+--------------------+--------------------+----------------------+--------------------------+---------------------+------------+
+|           1001 |    5001 | 2024-11-24       | 2024-11-24 14:30:00 |          
   100.00 | iPhone 12          | New York           |               100.00 |    
                   10 |                   0 | low        |
+|           1002 |    5002 | 2024-11-24       | 2024-11-24 03:30:00 |          
   120.00 | iPhone 12          | New York           |               100.00 |    
                   15 |                   0 | medium     |
+|           1003 |    5003 | 2024-11-24       | 2024-11-24 10:00:00 |          
   150.00 | Samsung S21        | Los Angeles        |               100.00 |    
                   30 |                   0 | medium     |
+|           1004 |    5004 | 2024-11-24       | 2024-11-24 16:00:00 |          
   300.00 | MacBook Pro        | high_risk_region1  |               200.00 |    
                    5 |                   0 | high       |
+|           1005 |    5005 | 2024-11-24       | 2024-11-24 11:00:00 |          
  1100.00 | iPad Pro           | Chicago            |               200.00 |    
                   10 |                   0 | high       |
++----------------+---------+------------------+---------------------+--------------------+--------------------+--------------------+----------------------+--------------------------+---------------------+------------+
+```
+
+## 更多帮助
+
+有关数据更新的更详细语法,请参考 
[UPDATE](../../sql-manual/sql-statements/data-modification/DML/UPDATE) 
命令手册。您也可以在 MySQL 客户端命令行中输入 `HELP UPDATE` 获取更多帮助。
+
diff --git 
a/i18n/zh-CN/docusaurus-plugin-content-docs/current/data-operate/update/update-of-unique-model.md
 
b/i18n/zh-CN/docusaurus-plugin-content-docs/current/data-operate/update/update-of-unique-model.md
index b8b31dbc7bf..9f85bfdb86e 100644
--- 
a/i18n/zh-CN/docusaurus-plugin-content-docs/current/data-operate/update/update-of-unique-model.md
+++ 
b/i18n/zh-CN/docusaurus-plugin-content-docs/current/data-operate/update/update-of-unique-model.md
@@ -10,9 +10,8 @@
 
 ## 整行更新
 
-使用 Doris 支持的 Stream Load、Broker Load、Routine Load、Insert Into 
等导入方式,向主键模型(Unique 模型)导入数据时,如果没有相应主键的数据行,则插入新数据;如果有相应主键的数据行,则进行更新。也就是说,Doris 
主键模型的导入是一种“upsert”模式。基于导入,对已有记录的更新,默认和导入一个新记录是完全一样的,因此可以参考数据导入的文档部分。
+使用 Doris 支持的 Stream Load、Broker Load、Routine Load、Insert Into 
等导入方式,向主键模型(Unique 模型)导入数据时,如果没有相应主键的数据行,则插入新数据;如果有相应主键的数据行,则进行更新。也就是说,Doris 
主键模型的导入是一种"upsert"模式。基于导入,对已有记录的更新,默认和导入一个新记录是完全一样的,因此可以参考数据导入的文档部分。
 
 ## 部分列更新
 
 关于主键模型(Unique Key 
Model)表的列更新详细说明,包括使用示例、灵活部分列更新和新行处理等内容,请参考[列更新](./partial-column-update.md#主键模型的列更新)文档。
-
diff --git 
a/i18n/zh-CN/docusaurus-plugin-content-docs/current/data-operate/update/update-overview.md
 
b/i18n/zh-CN/docusaurus-plugin-content-docs/current/data-operate/update/update-overview.md
index 40970c3f400..139d2a0313d 100644
--- 
a/i18n/zh-CN/docusaurus-plugin-content-docs/current/data-operate/update/update-overview.md
+++ 
b/i18n/zh-CN/docusaurus-plugin-content-docs/current/data-operate/update/update-overview.md
@@ -34,7 +34,7 @@ Doris 提供了两大类数据更新方法:**通过数据导入进行更新**
 
 ![img](/images/update-overview/update-by-loading.png)
 
-1.2.2. 通过 `UPDATE` DML语句更新
+#### 1.2.2. 通过 `UPDATE` DML语句更新
 
 Doris 支持标准的 SQL `UPDATE` 语句,允许用户根据 `WHERE` 
子句指定的条件对数据进行更新。这种方式非常灵活,支持复杂的更新逻辑,例如跨表关联更新。
 
@@ -53,7 +53,7 @@ WHERE t1.user_id = t2.user_id;
 
 **注意**:`UPDATE` 语句的执行过程是先扫描满足条件的数据,然后将更新后的数据重新写回表中。它适合低频、批量的更新任务。**不建议对** 
**`UPDATE`** **语句进行高并发操作**,因为并发的 `UPDATE` 在涉及相同主键时,无法保证数据的隔离性。
 
-#### 1.2.2. 通过 `INSERT INTO SELECT` DML语句更新
+#### 1.2.3. 通过 `INSERT INTO SELECT` DML语句更新
 
 由于Doris默认提供了UPSERT的语义,因此使用`INSERT INTO SELECT`也可以实现类似于`UPDATE`的更新效果。
 
diff --git 
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-4.x/data-operate/update/update-of-unique-model.md
 
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-3.x/data-operate/update/partial-column-update.md
similarity index 67%
copy from 
i18n/zh-CN/docusaurus-plugin-content-docs/version-4.x/data-operate/update/update-of-unique-model.md
copy to 
i18n/zh-CN/docusaurus-plugin-content-docs/version-3.x/data-operate/update/partial-column-update.md
index 141c568b8e2..96abe0468d4 100644
--- 
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-4.x/data-operate/update/update-of-unique-model.md
+++ 
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-3.x/data-operate/update/partial-column-update.md
@@ -1,20 +1,26 @@
 ---
 {
-    "title": "主键模型的导入更新",
+    "title": "列更新",
     "language": "zh-CN",
-    "description": "这篇文档主要介绍 Doris 主键模型基于导入的更新。"
+    "description": "这篇文档介绍如何在 Doris 中对主键模型和聚合模型表进行列更新。"
 }
 ---
 
-这篇文档主要介绍 Doris 主键模型基于导入的更新。
+部分列更新允许您更新表中的特定字段,而不需要修改所有字段。这篇文档介绍如何对主键模型(Unique Key Model)和聚合模型(Aggregate 
Key Model)表进行部分列更新。
 
-## 整行更新
+## 概述
 
-使用 Doris 支持的 Stream Load、Broker Load、Routine Load、Insert Into 
等导入方式,向主键模型(Unique 模型)导入数据时,如果没有相应主键的数据行,则插入新数据;如果有相应主键的数据行,则进行更新。也就是说,Doris 
主键模型的导入是一种“upsert”模式。基于导入,对已有记录的更新,默认和导入一个新记录是完全一样的,因此可以参考数据导入的文档部分。
+部分列更新是指直接更新表中某些字段值,而不是全部字段值。可以使用 Update 语句进行更新,这种 Update 
语句通常先读取整行数据,然后更新部分字段值,再写回。这种读写事务非常耗时,不适合大批量数据写入。Doris 
在主键模型的导入更新中,提供了直接插入或更新部分列数据的功能,不需要先读取整行数据,从而大幅提升更新效率。
 
-## 部分列更新
+部分列更新特别适用于:
 
-部分列更新是指直接更新表中某些字段值,而不是全部字段值。可以使用 Update 语句进行更新,这种 Update 
语句通常先读取整行数据,然后更新部分字段值,再写回。这种读写事务非常耗时,不适合大批量数据写入。Doris 
在主键模型的导入更新中,提供了直接插入或更新部分列数据的功能,不需要先读取整行数据,从而大幅提升更新效率。
+- 
实时动态列更新,需要在表中实时高频更新某些字段值。例如用户标签表中有一些关于用户最新行为信息的字段需要实时更新,以便广告/推荐系统能够据此进行实时分析和决策。
+- 将多张源表拼接成一张大宽表。
+- 数据修正。
+
+## 主键模型的列更新
+
+Doris 在主键模型的导入更新中,提供了直接插入或更新部分列数据的功能,不需要先读取整行数据,从而大幅提升更新效率。
 
 :::caution 注意
 
@@ -24,15 +30,9 @@
 4. 不支持在进行 Schema Change 的表上进行部分列更新。
 :::
 
-### 适用场景
-
-- 
实时动态列更新,需要在表中实时高频更新某些字段值。例如用户标签表中有一些关于用户最新行为信息的字段需要实时更新,以便广告/推荐系统能够据此进行实时分析和决策。
-- 将多张源表拼接成一张大宽表。
-- 数据修正。
-
 ### 使用示例
 
-假设 Doris 中存在一张订单表 order_tbl,其中订单 id 是 Key 列,订单状态和订单金额是 Value 列。数据状态如下:
+假设 Doris 中存在一张订单表 `order_tbl`,其中订单 id 是 Key 列,订单状态和订单金额是 Value 列。数据状态如下:
 
 | 订单 id | 订单金额 | 订单状态 |
 | ------ | -------- | -------- |
@@ -49,9 +49,9 @@
 
 此时,用户点击付款后,Doris 系统需要将订单 id 为 '1' 的订单状态变更为 '待发货'。
 
-#### 可以使用以下导入方式进行部分列更新
+### 使用导入方式进行部分列更新
 
-**StreamLoad/BrokerLoad/RoutineLoad**
+#### StreamLoad/BrokerLoad/RoutineLoad
 
 准备如下 csv 文件:
 
@@ -71,7 +71,7 @@ partial_columns:true
 curl --location-trusted -u root: -H "partial_columns:true" -H 
"column_separator:," -H "columns:order_id,order_status" -T /tmp/update.csv 
http://127.0.0.1:8030/api/db1/order_tbl/_stream_load
 ```
 
-**INSERT INTO**
+#### INSERT INTO
 
 在所有数据模型中,`INSERT INTO` 给定部分列时默认行为是整行写入。为了防止误用,在 Merge-on-Write 实现中,`INSERT 
INTO` 默认仍然保持整行 UPSERT 的语义。如果需要开启部分列更新的语义,需要设置如下 session variable:
 
@@ -82,7 +82,7 @@ INSERT INTO order_tbl (order_id, order_status) VALUES (1, 
'待发货');
 
 需要注意的是,控制 insert 语句是否开启严格模式的会话变量 `enable_insert_strict` 的默认值为 true,即 insert 
语句默认开启严格模式。在严格模式下进行部分列更新不允许更新不存在的 key。所以,在使用 insert 语句进行部分列更新时,如果希望能插入不存在的 
key,需要在 `enable_unique_key_partial_update` 设置为 true 的基础上,同时将 
`enable_insert_strict` 设置为 false。
 
-**Flink Connector**
+#### Flink Connector
 
 如果使用 Flink Connector,需要添加如下配置:
 
@@ -92,7 +92,7 @@ INSERT INTO order_tbl (order_id, order_status) VALUES (1, 
'待发货');
 
 同时在 `sink.properties.column` 中指定要导入的列(必须包含所有 key 列,否则无法更新)。
 
-#### 更新结果
+### 更新结果
 
 更新后结果如下:
 
@@ -120,7 +120,7 @@ INSERT INTO order_tbl (order_id, order_status) VALUES (1, 
'待发货');
 
 目前,同一批次数据写入任务(无论是导入任务还是 `INSERT INTO`)的所有行只能更新相同的列。如果需要更新不同列的数据,则需要分不同批次进行写入。
 
-## 灵活部分列更新
+### 灵活部分列更新
 
 此前,doris 支持的部分列更新功能限制了一次导入中每一行必须更新相同的列。现在,doris 
支持一种更加灵活的更新方式,它使得一次导入中的每一行可以更新不同的列(3.1.0版本及以上支持)。
 
@@ -130,15 +130,15 @@ INSERT INTO order_tbl (order_id, order_status) VALUES (1, 
'待发货');
 2. 在使用灵活列更新时导入文件必须为 json 格式的数据
 :::
 
-### 适用场景
+#### 适用场景
 
 在使用 CDC 的方式将某个数据系统的数据实时同步到 Doris 
中时,源端系统输出的记录可能并不是完整的行数据,而是只有主键和被更新的列的数据。在这种情况下,某个时间窗口内的一批数据中每一行更新的列可能都是不同的。此时,可以使用灵活列更新的方式来将数据导入到
 Doris 中。
 
-### 使用方式
+#### 使用方式
 
 **存量表开启灵活列更新功能**
 
-对于在旧版本 Doris 中已经建好的存量 Merge-On-Write 表,在升级 Doris 之后如果想要使用灵活列更新的功能,可以使用 `ALTER 
TALBE db1.tbl1 ENABLE FEATURE "UPDATE_FLEXIBLE_COLUMNS";` 来开启这一功能。执行完上述语句后使用 
`show create table db1.tbl1` 的结果中如果包含 `"enable_unique_key_skip_bitmap_column" = 
"true"` 则表示功能开启成功。注意,使用这一方式之前需要确保目标表已经开启了 light-schema-change 的功能。
+对于在旧版本 Doris 中已经建好的存量 Merge-On-Write 表,在升级 Doris 之后如果想要使用灵活列更新的功能,可以使用 `ALTER 
TABLE db1.tbl1 ENABLE FEATURE "UPDATE_FLEXIBLE_COLUMNS";` 来开启这一功能。执行完上述语句后使用 
`show create table db1.tbl1` 的结果中如果包含 `"enable_unique_key_skip_bitmap_column" = 
"true"` 则表示功能开启成功。注意,使用这一方式之前需要确保目标表已经开启了 light-schema-change 的功能。
 
 **新建表使用灵活列更新功能**
 
@@ -165,7 +165,7 @@ unique_key_update_mode:UPDATE_FLEXIBLE_COLUMNS
 'sink.properties.unique_key_update_mode' = 'UPDATE_FLEXIBLE_COLUMNS'
 ```
 
-### 示例
+#### 示例
 
 假设有如下表
 
@@ -242,131 +242,15 @@ MySQL [email protected]:d1> select * from t1;
 +---+-----+------+-----+------+--------+
 ```
 
-### 限制与注意事项
+#### 限制与注意事项
 
 1. 和之前的部分列更新相同,灵活列更新要求导入的每一行数据需要包括所有的 Key 列,不满足这一要求的行数据将被过滤掉,同时计入 `filter 
rows` 的计数中,如果 `filtered rows` 的数量超过了本次导入 `max_filter_ratio` 
所能容忍的上限,则整个导入将会失败。同时,被过滤的数据会在 error log 留下一条日志。
 
 2. 灵活列更新导入中每一个 json 对象中的键值对只有当它的 Key 
和目标表中某一列的列名一致时才是有效的,不满足这一要求的键值对将被忽略。同时,Key 为 
`__DORIS_VERSION_COL__`/`__DORIS_ROW_STORE_COL__`/`__DORIS_SKIP_BITMAP_COL__` 
的键值对也将被忽略。
 
-3. 当目标表的表属性中设置了 `function_column.sequence_type` 这一属性时,灵活列更新的导入可以通过在 json 对象中包括 
Key 为 `__DORIS_SEQUENCE_COL__` 的键值对来指定目标表中 `__DORIS_SEQUENCE_COL__` 列的值。对于不指定 
`__DORIS_SEQUENCE_COL__` 列的值的行,如果这一行的 Key 在原表中存在,则这一行 `__DORIS_SEQUENCE_COL__` 
列的值将被填充为旧行中对应的值,否则该列的值将被填充为 `null` 值
-
-例如,对于下表:
-```sql
-CREATE TABLE t2 (
-  `k` int(11) NULL, 
-  `v1` BIGINT NULL,
-  `v2` BIGINT NULL DEFAULT "9876",
-  `v3` BIGINT NOT NULL,
-  `v4` BIGINT NOT NULL DEFAULT "1234",
-  `v5` BIGINT NULL
-) UNIQUE KEY(`k`) DISTRIBUTED BY HASH(`k`) BUCKETS 1
-PROPERTIES(
-"replication_num" = "3",
-"enable_unique_key_merge_on_write" = "true",
-"enable_unique_key_skip_bitmap_column" = "true",
-"function_column.sequence_type" = "int");
-```
-
-表中有如下原始数据:
-```sql
-+---+----+----+----+----+----+----------------------+
-| k | v1 | v2 | v3 | v4 | v5 |__DORIS_SEQUENCE_COL__|
-+---+----+----+----+----+----+----------------------+
-| 0 | 0  | 0  | 0  | 0  | 0  | 0                    |
-| 1 | 1  | 1  | 1  | 1  | 10 | 10                   |
-| 2 | 2  | 2  | 2  | 2  | 20 | 20                   |
-| 3 | 3  | 3  | 3  | 3  | 30 | 30                   |
-| 4 | 4  | 4  | 4  | 4  | 40 | 40                   |
-| 5 | 5  | 5  | 5  | 5  | 50 | 50                   |
-+---+----+----+----+----+----+----------------------+
-```
-
-通过灵活列更新导入如下数据:
-```json
-{"k": 1, "v1": 111, "v5": 9, "__DORIS_SEQUENCE_COL__": 9}
-{"k": 2, "v2": 222, "v5": 25, "__DORIS_SEQUENCE_COL__": 25}
-{"k": 3, "v3": 333}
-{"k": 4, "v4": 444, "v5": 50, "v1": 411, "v3": 433, "v2": null, 
"__DORIS_SEQUENCE_COL__": 50}
-{"k": 5, "v5": null, "__DORIS_SEQUENCE_COL__": null}
-{"k": 6, "v1": 611, "v3": 633}
-{"k": 7, "v3": 733, "v5": 300, "__DORIS_SEQUENCE_COL__": 300}
-```
-
-最终表中的数据如下:
-```sql
-+---+--------+--------+-----+------+--------+
-| k | v1     | v2     | v3  | v4   | v5     |
-+---+--------+--------+-----+------+--------+
-| 0 | 0      | 0      | 0   | 0    | 0      |
-| 1 | 1      | 1      | 1   | 1    | 1      |
-| 5 | 5      | 5      | 5   | 5    | 5      |
-| 2 | 2      | 222    | 2   | 2    | 25     |
-| 3 | 3      | 3      | 333 | 3    | 3      |
-| 4 | 411    | <null> | 433 | 444  | 50     |
-| 6 | 611    | 9876   | 633 | 1234 | <null> |
-| 7 | <null> | 9876   | 733 | 1234 | 300    |
-+---+--------+--------+-----+------+--------+
-```
-
-4. 当目标表的表属性中设置了 `function_column.sequence_col` 这一属性时,灵活列更新导入数据的 json 对象中 Key 为 
`__DORIS_SEQUENCE_COL__` 的键值对将被忽略,导入中某一行 `__DORIS_SEQUENCE_COL__` 列的值将与这一行中表属性 
`function_column.sequence_col` 所指定的列最终的值完全一致。
-
-例如,对于下表:
-```sql
-CREATE TABLE t3 (
-  `k` int(11) NULL, 
-  `v1` BIGINT NULL,
-  `v2` BIGINT NULL DEFAULT "9876",
-  `v3` BIGINT NOT NULL,
-  `v4` BIGINT NOT NULL DEFAULT "1234",
-  `v5` BIGINT NULL DEFAULT "31"
-) UNIQUE KEY(`k`) DISTRIBUTED BY HASH(`k`) BUCKETS 1
-PROPERTIES(
-"replication_num" = "3",
-"enable_unique_key_merge_on_write" = "true",
-"enable_unique_key_skip_bitmap_column" = "true",
-"function_column.sequence_col" = "v5");
-```
-
-表中有如下原始数据:
-```sql
-+---+----+----+----+----+----+----------------------+
-| k | v1 | v2 | v3 | v4 | v5 |__DORIS_SEQUENCE_COL__|
-+---+----+----+----+----+----+----------------------+
-| 0 | 0  | 0  | 0  | 0  | 0  | 0                    |
-| 1 | 1  | 1  | 1  | 1  | 10 | 10                   |
-| 2 | 2  | 2  | 2  | 2  | 20 | 20                   |
-| 3 | 3  | 3  | 3  | 3  | 30 | 30                   |
-| 4 | 4  | 4  | 4  | 4  | 40 | 40                   |
-| 5 | 5  | 5  | 5  | 5  | 50 | 50                   |
-+---+----+----+----+----+----+----------------------+
-```
-
-通过灵活列更新导入如下数据:
-```json
-{"k": 1, "v1": 111, "v5": 9}
-{"k": 2, "v2": 222, "v5": 25}
-{"k": 3, "v3": 333}
-{"k": 4, "v4": 444, "v5": 50, "v1": 411, "v3": 433, "v2": null}
-{"k": 5, "v5": null}
-{"k": 6, "v1": 611, "v3": 633}
-{"k": 7, "v3": 733, "v5": 300}
-```
+3. 不支持在有 Variant 列的表上进行灵活列更新。
 
-最终表中的数据如下:
-```sql
-+---+--------+--------+-----+------+-----+
-| k | v1     | v2     | v3  | v4   | v5  |
-+---+--------+--------+-----+------+-----+
-| 0 | 0      | 0      | 0   | 0    | 0   |
-| 1 | 1      | 1      | 1   | 1    | 10  |
-| 5 | 5      | 5      | 5   | 5    | 50  |
-| 2 | 2      | 222    | 2   | 2    | 25  |
-| 3 | 3      | 3      | 333 | 3    | 30  |
-| 4 | 411    | <null> | 433 | 444  | 50  |
-| 6 | 611    | 9876   | 633 | 1234 | 31  |
-| 7 | <null> | 9876   | 733 | 1234 | 300 |
-+---+--------+--------+-----+------+-----+
-```
+4. 不支持在有同步物化视图的表上进行灵活列更新。
 
 5. 使用灵活列更新时不能指定或开启如下一些导入属参数:
     - 不能指定 `merge_type` 参数
@@ -381,12 +265,7 @@ PROPERTIES(
     - 不能指定 `group_commit` 参数
     - 不能指定 `where` 参数
 
-6. 不支持在有 Variant 列的表上进行灵活列更新。
-
-7. 不支持在有同步物化视图的表上进行灵活列更新。
-
-
-## 部分列更新/灵活列更新中对新插入的行的处理
+### 部分列更新/灵活列更新中对新插入的行的处理
 
 session variable或导入属性`partial_update_new_key_behavior`用于控制部分列更新和灵活列更新中插入的新行的行为。
 
@@ -455,3 +334,53 @@ mysql> select * from user_profile;
 +------+-------+------+----------+---------+---------------------+
 ```
 
+## 聚合模型的列更新
+
+Aggregate 表主要在预聚合场景使用而非数据更新的场景使用,但也可以通过将聚合函数设置为 REPLACE_IF_NOT_NULL 来实现部分列更新效果。
+
+### 建表
+
+将需要进行列更新的字段对应的聚合函数设置为`REPLACE_IF_NOT_NULL`
+
+```sql
+CREATE TABLE order_tbl (
+  order_id int(11) NULL,
+  order_amount int(11) REPLACE_IF_NOT_NULL NULL,
+  order_status varchar(100) REPLACE_IF_NOT_NULL NULL
+) ENGINE=OLAP
+AGGREGATE KEY(order_id)
+COMMENT 'OLAP'
+DISTRIBUTED BY HASH(order_id) BUCKETS 1
+PROPERTIES (
+"replication_allocation" = "tag.location.default: 1"
+);
+```
+
+### 数据写入
+
+无论是 Stream Load、Broker Load、Routine Load 还是`INSERT INTO`, 直接写入要更新的字段的数据即可
+
+### 示例
+
+与前面例子相同,对应的 Stream Load 命令为(不需要额外的 header):
+
+```shell
+$ cat update.csv
+
+1,待发货
+
+curl  --location-trusted -u root: -H "column_separator:," -H 
"columns:order_id,order_status" -T ./update.csv 
http://127.0.0.1:8030/api/db1/order_tbl/_stream_load
+```
+
+对应的`INSERT INTO`语句为(不需要额外设置 session variable):
+
+```sql
+INSERT INTO order_tbl (order_id, order_status) values (1,'待发货');
+```
+
+### 部分列更新使用注意
+
+Aggregate Key 
模型在写入过程中不做任何额外处理,所以写入性能不受影响,与普通的数据导入相同。但是在查询时进行聚合的代价较大,典型的聚合查询性能相比 Unique Key 
模型的 Merge-on-Write 实现会有 5-10 倍的下降。
+
+由于 `REPLACE_IF_NOT_NULL` 聚合函数仅在非 NULL 值时才会生效,因此用户无法将某个字段值修改为 NULL 值。
+
diff --git 
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-3.x/data-operate/update/unique-update-sql.md
 
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-3.x/data-operate/update/unique-update-sql.md
new file mode 100644
index 00000000000..67ff892679e
--- /dev/null
+++ 
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-3.x/data-operate/update/unique-update-sql.md
@@ -0,0 +1,123 @@
+---
+{
+    "title": "使用 UPDATE 命令更新数据",
+    "language": "zh-CN",
+    "description": "这篇文档介绍如何在 Doris 中使用 UPDATE 命令修改数据。"
+}
+---
+
+这篇文档介绍如何在 Doris 中使用 `UPDATE` 命令修改数据。`UPDATE` 命令仅适用于主键模型(Unique Key Model)表。
+
+## 适用场景
+
+- 小规模数据更新:适用于需要修正少量数据的场景,例如修正某些记录中的错误字段,或更新特定字段的状态(如订单状态更新)。
+
+- 某些字段的 ETL 批量处理:适用于对某个字段进行大规模更新的场景,常见于 ETL 处理场景。注意:大规模数据更新应该是不频繁的。
+
+## 工作原理
+
+查询引擎使用自身的过滤逻辑来识别需要更新的行。然后,使用主键模型的 Value 
列逻辑,用新数据替换旧数据。需要更新的行被修改后重新插入到表中,以实现行级更新。
+
+### 同步性
+
+Doris 中的 `UPDATE` 语法是同步的,这意味着一旦 `UPDATE` 语句成功执行,更新操作就已完成,数据立即可见。
+
+### 性能
+
+`UPDATE` 语句的性能与需要更新的行数和查询条件的效率密切相关。
+
+- 需要更新的行数:需要更新的行数越多,`UPDATE` 语句的执行速度就越慢。对于小规模更新,Doris 支持与 `INSERT INTO` 
语句相似的频率。对于大规模更新,由于执行时间较长,仅适用于不频繁的调用。
+
+- 查询条件的效率:`UPDATE` 实现首先读取满足查询条件的行。因此,如果查询条件高效,`UPDATE` 
速度就会快。理想情况下,条件列应该命中索引或分区桶裁剪,这样 Doris 
就不需要扫描整个表,可以快速定位需要更新的行,从而提高更新效率。强烈建议不要在条件列中包含值列。
+
+## 使用示例
+
+假设在金融风控场景中存在一张交易明细表,结构如下:
+
+```sql
+CREATE TABLE transaction_details (
+  transaction_id BIGINT NOT NULL,        -- 唯一交易 ID
+  user_id BIGINT NOT NULL,               -- 用户 ID
+  transaction_date DATE NOT NULL,        -- 交易日期
+  transaction_time DATETIME NOT NULL,    -- 交易时间
+  transaction_amount DECIMAL(18, 2),     -- 交易金额
+  transaction_device STRING,             -- 交易设备
+  transaction_region STRING,             -- 交易地区
+  average_daily_amount DECIMAL(18, 2),   -- 最近 3 个月的平均日交易金额
+  recent_transaction_count INT,          -- 最近 7 天的交易次数
+  has_dispute_history BOOLEAN,           -- 是否有争议历史
+  risk_level STRING                      -- 风险等级
+)
+UNIQUE KEY(transaction_id)
+DISTRIBUTED BY HASH(transaction_id) BUCKETS 16
+PROPERTIES (
+  "replication_num" = "3",               -- 副本数,默认为 3
+  "enable_unique_key_merge_on_write" = "true"  -- 启用 MOW 模式,支持合并更新
+);
+```
+
+存在以下交易数据:
+
+```sql
++----------------+---------+------------------+---------------------+--------------------+--------------------+--------------------+----------------------+--------------------------+---------------------+------------+
+| transaction_id | user_id | transaction_date | transaction_time    | 
transaction_amount | transaction_device | transaction_region | 
average_daily_amount | recent_transaction_count | has_dispute_history | 
risk_level |
++----------------+---------+------------------+---------------------+--------------------+--------------------+--------------------+----------------------+--------------------------+---------------------+------------+
+|           1001 |    5001 | 2024-11-24       | 2024-11-24 14:30:00 |          
   100.00 | iPhone 12          | New York           |               100.00 |    
                   10 |                   0 | NULL       |
+|           1002 |    5002 | 2024-11-24       | 2024-11-24 03:30:00 |          
   120.00 | iPhone 12          | New York           |               100.00 |    
                   15 |                   0 | NULL       |
+|           1003 |    5003 | 2024-11-24       | 2024-11-24 10:00:00 |          
   150.00 | Samsung S21        | Los Angeles        |               100.00 |    
                   30 |                   0 | NULL       |
+|           1004 |    5004 | 2024-11-24       | 2024-11-24 16:00:00 |          
   300.00 | MacBook Pro        | high_risk_region1  |               200.00 |    
                    5 |                   0 | NULL       |
+|           1005 |    5005 | 2024-11-24       | 2024-11-24 11:00:00 |          
  1100.00 | iPad Pro           | Chicago            |               200.00 |    
                   10 |                   0 | NULL       |
++----------------+---------+------------------+---------------------+--------------------+--------------------+--------------------+----------------------+--------------------------+---------------------+------------+
+```
+
+根据以下风控规则更新所有当日交易记录的风险等级:
+1. 有争议历史的交易风险等级为 high。
+2. 高风险地区的交易风险等级为 high。
+3. 异常金额(超过日均金额 5 倍)的交易风险等级为 high。
+4. 最近 7 天频繁交易:
+   a. 交易次数 > 50 次的交易风险等级为 high。
+   b. 交易次数在 20 到 50 次之间的交易风险等级为 medium。
+5. 非工作时间(凌晨 2 点到 4 点)的交易风险等级为 medium。
+6. 默认风险等级为 low。
+
+```sql
+UPDATE transaction_details
+SET risk_level = CASE
+  -- 有争议历史或高风险地区的交易
+  WHEN has_dispute_history = TRUE THEN 'high'
+  WHEN transaction_region IN ('high_risk_region1', 'high_risk_region2') THEN 
'high'
+
+  -- 异常交易金额
+  WHEN transaction_amount > 5 * average_daily_amount THEN 'high'
+
+  -- 最近 7 天高频交易
+  WHEN recent_transaction_count > 50 THEN 'high'
+  WHEN recent_transaction_count BETWEEN 20 AND 50 THEN 'medium'
+
+  -- 非工作时间交易
+  WHEN HOUR(transaction_time) BETWEEN 2 AND 4 THEN 'medium'
+
+  -- 默认风险等级
+  ELSE 'low'
+END
+WHERE transaction_date = '2024-11-24';
+```
+
+更新后的数据如下:
+
+```sql
++----------------+---------+------------------+---------------------+--------------------+--------------------+--------------------+----------------------+--------------------------+---------------------+------------+
+| transaction_id | user_id | transaction_date | transaction_time    | 
transaction_amount | transaction_device | transaction_region | 
average_daily_amount | recent_transaction_count | has_dispute_history | 
risk_level |
++----------------+---------+------------------+---------------------+--------------------+--------------------+--------------------+----------------------+--------------------------+---------------------+------------+
+|           1001 |    5001 | 2024-11-24       | 2024-11-24 14:30:00 |          
   100.00 | iPhone 12          | New York           |               100.00 |    
                   10 |                   0 | low        |
+|           1002 |    5002 | 2024-11-24       | 2024-11-24 03:30:00 |          
   120.00 | iPhone 12          | New York           |               100.00 |    
                   15 |                   0 | medium     |
+|           1003 |    5003 | 2024-11-24       | 2024-11-24 10:00:00 |          
   150.00 | Samsung S21        | Los Angeles        |               100.00 |    
                   30 |                   0 | medium     |
+|           1004 |    5004 | 2024-11-24       | 2024-11-24 16:00:00 |          
   300.00 | MacBook Pro        | high_risk_region1  |               200.00 |    
                    5 |                   0 | high       |
+|           1005 |    5005 | 2024-11-24       | 2024-11-24 11:00:00 |          
  1100.00 | iPad Pro           | Chicago            |               200.00 |    
                   10 |                   0 | high       |
++----------------+---------+------------------+---------------------+--------------------+--------------------+--------------------+----------------------+--------------------------+---------------------+------------+
+```
+
+## 更多帮助
+
+有关数据更新的更详细语法,请参考 
[UPDATE](../../sql-manual/sql-statements/data-modification/DML/UPDATE) 
命令手册。您也可以在 MySQL 客户端命令行中输入 `HELP UPDATE` 获取更多帮助。
+
diff --git 
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-3.x/data-operate/update/update-of-aggregate-model.md
 
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-3.x/data-operate/update/update-of-aggregate-model.md
index 43db19b60ff..5914c6ae65f 100644
--- 
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-3.x/data-operate/update/update-of-aggregate-model.md
+++ 
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-3.x/data-operate/update/update-of-aggregate-model.md
@@ -12,52 +12,6 @@
 
 使用 Doris 支持的 Stream Load,Broker Load,Routine Load,Insert Into 等导入方式,往聚合模型(Agg 
模型)中进行数据导入时,都会将新的值与旧的聚合值,根据列的聚合函数产出新的聚合值,这个值可能是插入时产出,也可能是异步 Compaction 
时产出,但是用户查询时,都会得到一样的返回值。
 
-## 聚合模型的部分列更新
+## 部分列更新
 
-Aggregate 表主要在预聚合场景使用而非数据更新的场景使用,但也可以通过将聚合函数设置为 REPLACE_IF_NOT_NULL 来实现部分列更新效果。
-
-**建表**
-
-将需要进行列更新的字段对应的聚合函数设置为`REPLACE_IF_NOT_NULL`
-
-```sql
-CREATE TABLE order_tbl (
-  order_id int(11) NULL,
-  order_amount int(11) REPLACE_IF_NOT_NULL NULL,
-  order_status varchar(100) REPLACE_IF_NOT_NULL NULL
-) ENGINE=OLAP
-AGGREGATE KEY(order_id)
-COMMENT 'OLAP'
-DISTRIBUTED BY HASH(order_id) BUCKETS 1
-PROPERTIES (
-"replication_allocation" = "tag.location.default: 1"
-);
-```
-
-**数据写入**
-
-无论是 Stream Load、Broker Load、Routine Load 还是`INSERT INTO`, 直接写入要更新的字段的数据即可
-
-**示例**
-
-与前面例子相同,对应的 Stream Load 命令为(不需要额外的 header):
-
-```shell
-$ cat update.csv
-
-1,To be shipped
-
-curl  --location-trusted -u root: -H "column_separator:," -H 
"columns:order_id,order_status" -T /tmp/update.csv 
http://127.0.0.1:8030/api/db1/order_tbl/_stream_load
-```
-
-对应的`INSERT INTO`语句为(不需要额外设置 session variable):
-
-```sql
-INSERT INTO order_tbl (order_id, order_status) values (1,'待发货');
-```
-
-## 部分列更新使用注意
-
-Aggregate Key 
模型在写入过程中不做任何额外处理,所以写入性能不受影响,与普通的数据导入相同。但是在查询时进行聚合的代价较大,典型的聚合查询性能相比 Unique Key 
模型的 Merge-on-Write 实现会有 5-10 倍的下降。
-
-由于 `REPLACE_IF_NOT_NULL` 聚合函数仅在非 NULL 值时才会生效,因此用户无法将某个字段值修改为 NULL 值。
+关于聚合模型(Aggregate Key 
Model)表的列更新详细说明,包括建表、数据写入示例和使用注意事项等内容,请参考[列更新](./partial-column-update.md#聚合模型的列更新)文档。
diff --git 
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-3.x/data-operate/update/update-of-unique-model.md
 
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-3.x/data-operate/update/update-of-unique-model.md
index dc7bdd4b0a6..9f85bfdb86e 100644
--- 
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-3.x/data-operate/update/update-of-unique-model.md
+++ 
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-3.x/data-operate/update/update-of-unique-model.md
@@ -10,381 +10,8 @@
 
 ## 整行更新
 
-使用 Doris 支持的 Stream Load、Broker Load、Routine Load、Insert Into 
等导入方式,向主键模型(Unique 模型)导入数据时,如果没有相应主键的数据行,则插入新数据;如果有相应主键的数据行,则进行更新。也就是说,Doris 
主键模型的导入是一种“upsert”模式。基于导入,对已有记录的更新,默认和导入一个新记录是完全一样的,因此可以参考数据导入的文档部分。
+使用 Doris 支持的 Stream Load、Broker Load、Routine Load、Insert Into 
等导入方式,向主键模型(Unique 模型)导入数据时,如果没有相应主键的数据行,则插入新数据;如果有相应主键的数据行,则进行更新。也就是说,Doris 
主键模型的导入是一种"upsert"模式。基于导入,对已有记录的更新,默认和导入一个新记录是完全一样的,因此可以参考数据导入的文档部分。
 
 ## 部分列更新
 
-部分列更新是指直接更新表中某些字段值,而不是全部字段值。可以使用 Update 语句进行更新,这种 Update 
语句通常先读取整行数据,然后更新部分字段值,再写回。这种读写事务非常耗时,不适合大批量数据写入。Doris 
在主键模型的导入更新中,提供了直接插入或更新部分列数据的功能,不需要先读取整行数据,从而大幅提升更新效率。
-
-:::caution 注意
-
-1. 2.0 版本仅在 Unique Key 的 Merge-on-Write 实现中支持部分列更新能力。
-2. 从 2.0.2 版本开始,支持使用 INSERT INTO 进行部分列更新。
-3. 不支持在有同步物化视图的表上进行部分列更新。
-4. 不支持在进行 Schema Change 的表上进行部分列更新。
-:::
-
-### 适用场景
-
-- 
实时动态列更新,需要在表中实时高频更新某些字段值。例如用户标签表中有一些关于用户最新行为信息的字段需要实时更新,以便广告/推荐系统能够据此进行实时分析和决策。
-- 将多张源表拼接成一张大宽表。
-- 数据修正。
-
-### 使用示例
-
-假设 Doris 中存在一张订单表 order_tbl,其中订单 id 是 Key 列,订单状态和订单金额是 Value 列。数据状态如下:
-
-| 订单 id | 订单金额 | 订单状态 |
-| ------ | -------- | -------- |
-| 1      | 100      | 待付款   |
-
-```sql
-+----------+--------------+--------------+
-| order_id | order_amount | order_status |
-+----------+--------------+--------------+
-| 1        |          100 | 待付款        |
-+----------+--------------+--------------+
-1 row in set (0.01 sec)
-```
-
-此时,用户点击付款后,Doris 系统需要将订单 id 为 '1' 的订单状态变更为 '待发货'。
-
-#### 可以使用以下导入方式进行部分列更新
-
-**StreamLoad/BrokerLoad/RoutineLoad**
-
-准备如下 csv 文件:
-
-```
-1,待发货
-```
-
-在导入时添加如下 header:
-
-```sql
-partial_columns:true
-```
-
-同时在 `columns` 中指定要导入的列(必须包含所有 key 列,否则无法更新)。下面是一个 Stream Load 的例子:
-
-```sql
-curl --location-trusted -u root: -H "partial_columns:true" -H 
"column_separator:," -H "columns:order_id,order_status" -T /tmp/update.csv 
http://127.0.0.1:8030/api/db1/order_tbl/_stream_load
-```
-
-**INSERT INTO**
-
-在所有数据模型中,`INSERT INTO` 给定部分列时默认行为是整行写入。为了防止误用,在 Merge-on-Write 实现中,`INSERT 
INTO` 默认仍然保持整行 UPSERT 的语义。如果需要开启部分列更新的语义,需要设置如下 session variable:
-
-```sql
-SET enable_unique_key_partial_update=true;
-INSERT INTO order_tbl (order_id, order_status) VALUES (1, '待发货');
-```
-
-需要注意的是,控制 insert 语句是否开启严格模式的会话变量 `enable_insert_strict` 的默认值为 true,即 insert 
语句默认开启严格模式。在严格模式下进行部分列更新不允许更新不存在的 key。所以,在使用 insert 语句进行部分列更新时,如果希望能插入不存在的 
key,需要在 `enable_unique_key_partial_update` 设置为 true 的基础上,同时将 
`enable_insert_strict` 设置为 false。
-
-**Flink Connector**
-
-如果使用 Flink Connector,需要添加如下配置:
-
-```sql
-'sink.properties.partial_columns' = 'true',
-```
-
-同时在 `sink.properties.column` 中指定要导入的列(必须包含所有 key 列,否则无法更新)。
-
-#### 更新结果
-
-更新后结果如下:
-
-```sql
-+----------+--------------+--------------+
-| order_id | order_amount | order_status |
-+----------+--------------+--------------+
-| 1        |          100 | 待发货        |
-+----------+--------------+--------------+
-1 row in set (0.01 sec)
-```
-
-### 使用注意
-
-由于 Merge-on-Write 实现需要在数据写入时进行整行数据的补齐,以保证最优的查询性能,因此使用 Merge-on-Write 
实现进行部分列更新会导致部分导入性能下降。
-
-写入性能优化建议:
-
-- 使用配备 NVMe 的 SSD,或者极速 SSD 云盘。因为补齐数据时会大量读取历史数据,产生较高的读 IOPS 以及读吞吐。
-- 开启行存能够大大减少补齐数据时产生的 IOPS,导入性能提升明显。用户可以在建表时通过如下 property 来开启行存:
-
-```Plain
-"store_row_column" = "true"
-```
-
-目前,同一批次数据写入任务(无论是导入任务还是 `INSERT INTO`)的所有行只能更新相同的列。如果需要更新不同列的数据,则需要分不同批次进行写入。
-
-在未来版本中,将支持灵活的列更新,用户可以在同一批导入中,每一行更新不同的列。
-
-## 灵活部分列更新
-
-> 该功能自 3.1.0 版本支持
-
-此前,doris 支持的部分列更新功能限制了一次导入中每一行必须更新相同的列。现在,doris 
支持一种更加灵活的更新方式,它使得一次导入中的每一行可以更新不同的列。
-
-:::caution 注意:
-
-1. 目前只有 stream load 这一种导入方式以及使用 stream load 作为其导入方式的工具 (如 
doris-flink-connector) 支持灵活列更新功能
-2. 在使用灵活列更新时导入文件必须为 json 格式的数据
-:::
-
-### 适用场景
-
-在使用 CDC 的方式将某个数据系统的数据实时同步到 Doris 
中时,源端系统输出的记录可能并不是完整的行数据,而是只有主键和被更新的列的数据。在这种情况下,某个时间窗口内的一批数据中每一行更新的列可能都是不同的。此时,可以使用灵活列更新的方式来将数据导入到
 Doris 中。
-
-### 使用方式
-
-**存量表开启灵活列更新功能**
-
-对于在旧版本 Doris 中已经建好的存量 Merge-On-Write 表,在升级 Doris 之后如果想要使用灵活列更新的功能,可以使用 `ALTER 
TALBE db1.tbl1 ENABLE FEATURE "UPDATE_FLEXIBLE_COLUMNS";` 来开启这一功能。执行完上述语句后使用 
`show create table db1.tbl1` 的结果中如果包含 `"enable_unique_key_skip_bitmap_column" = 
"true"` 则表示功能开启成功。注意,使用这一方式之前需要确保目标表已经开启了 light-schema-change 的功能。
-
-**新建表使用灵活列更新功能**
-
-对于新建的表,如果需要使用灵活列更新功能,建表时需要指定如下表属性,以开启 Merge-on-Write 实现,同时使得表具有灵活列更新所需要的 
`bitmap` 隐藏列。
-
-```Plain
-"enable_unique_key_merge_on_write" = "true"
-"enable_unique_key_skip_bitmap_column" = "true"
-```
-
-**StreamLoad**
-
-在使用 Stream Load 导入时添加如下 header
-
-```Plain
-unique_key_update_mode:UPDATE_FLEXIBLE_COLUMNS
-```
-
-**Flink Doris Connector**
-
-如果使用 Flink Doris Connector, 需要添加如下配置:
-
-```Plain
-'sink.properties.unique_key_update_mode' = 'UPDATE_FLEXIBLE_COLUMNS'
-```
-
-### 示例
-
-假设有如下表
-
-```sql
-CREATE TABLE t1 (
-  `k` int(11) NULL, 
-  `v1` BIGINT NULL,
-  `v2` BIGINT NULL DEFAULT "9876",
-  `v3` BIGINT NOT NULL,
-  `v4` BIGINT NOT NULL DEFAULT "1234",
-  `v5` BIGINT NULL
-) UNIQUE KEY(`k`) DISTRIBUTED BY HASH(`k`) BUCKETS 1
-PROPERTIES(
-"replication_num" = "3",
-"enable_unique_key_merge_on_write" = "true",
-"enable_unique_key_skip_bitmap_column" = "true");
-```
-
-表中有如下原始数据
-
-```sql
-MySQL [email protected]:d1> select * from t1;
-+---+----+----+----+----+----+
-| k | v1 | v2 | v3 | v4 | v5 |
-+---+----+----+----+----+----+
-| 0 | 0  | 0  | 0  | 0  | 0  |
-| 1 | 1  | 1  | 1  | 1  | 1  |
-| 2 | 2  | 2  | 2  | 2  | 2  |
-| 3 | 3  | 3  | 3  | 3  | 3  |
-| 4 | 4  | 4  | 4  | 4  | 4  |
-| 5 | 5  | 5  | 5  | 5  | 5  |
-+---+----+----+----+----+----+
-```
-
-现在通过灵活列更新导入来更新其中的一些行的字段
-
-```shell
-$ cat test1.json
-```
-```json
-{"k": 0, "__DORIS_DELETE_SIGN__": 1}
-{"k": 1, "v1": 10}
-{"k": 2, "v2": 20, "v5": 25}
-{"k": 3, "v3": 30}
-{"k": 4, "v4": 20, "v1": 43, "v3": 99}
-{"k": 5, "v5": null}
-{"k": 6, "v1": 999, "v3": 777}
-{"k": 2, "v4": 222}
-{"k": 1, "v2": 111, "v3": 111}
-```
-```shell
-curl --location-trusted -u root: \
--H "strict_mode:false" \
--H "format:json" \
--H "read_json_by_line:true" \
--H "unique_key_update_mode:UPDATE_FLEXIBLE_COLUMNS" \
--T test1.json \
--XPUT http://<host>:<http_port>/api/d1/t1/_stream_load
-```
-
-更新后表中的数据如下:
-
-```sql
-MySQL [email protected]:d1> select * from t1;
-+---+-----+------+-----+------+--------+
-| k | v1  | v2   | v3  | v4   | v5     |
-+---+-----+------+-----+------+--------+
-| 1 | 10  | 111  | 111 | 1    | 1      |
-| 2 | 2   | 20   | 2   | 222  | 25     |
-| 3 | 3   | 3    | 30  | 3    | 3      |
-| 4 | 43  | 4    | 99  | 20   | 4      |
-| 5 | 5   | 5    | 5   | 5    | <null> |
-| 6 | 999 | 9876 | 777 | 1234 | <null> |
-+---+-----+------+-----+------+--------+
-```
-
-### 限制与注意事项
-
-1. 和之前的部分列更新相同,灵活列更新要求导入的每一行数据需要包括所有的 Key 列,不满足这一要求的行数据将被过滤掉,同时计入 `filter 
rows` 的计数中,如果 `filtered rows` 的数量超过了本次导入 `max_filter_ratio` 
所能容忍的上限,则整个导入将会失败。同时,被过滤的数据会在 error log 留下一条日志。
-
-2. 灵活列更新导入中每一个 json 对象中的键值对只有当它的 Key 
和目标表中某一列的列名一致时才是有效的,不满足这一要求的键值对将被忽略。同时,Key 为 
`__DORIS_VERSION_COL__`/`__DORIS_ROW_STORE_COL__`/`__DORIS_SKIP_BITMAP_COL__` 
的键值对也将被忽略。
-
-3. 当目标表的表属性中设置了 `function_column.sequence_type` 这一属性时,灵活列更新的导入可以通过在 json 对象中包括 
Key 为 `__DORIS_SEQUENCE_COL__` 的键值对来指定目标表中 `__DORIS_SEQUENCE_COL__` 列的值。对于不指定 
`__DORIS_SEQUENCE_COL__` 列的值的行,如果这一行的 Key 在原表中存在,则这一行 `__DORIS_SEQUENCE_COL__` 
列的值将被填充为旧行中对应的值,否则该列的值将被填充为 `null` 值
-
-例如,对于下表:
-```sql
-CREATE TABLE t2 (
-  `k` int(11) NULL, 
-  `v1` BIGINT NULL,
-  `v2` BIGINT NULL DEFAULT "9876",
-  `v3` BIGINT NOT NULL,
-  `v4` BIGINT NOT NULL DEFAULT "1234",
-  `v5` BIGINT NULL
-) UNIQUE KEY(`k`) DISTRIBUTED BY HASH(`k`) BUCKETS 1
-PROPERTIES(
-"replication_num" = "3",
-"enable_unique_key_merge_on_write" = "true",
-"enable_unique_key_skip_bitmap_column" = "true",
-"function_column.sequence_type" = "int");
-```
-
-表中有如下原始数据:
-```sql
-+---+----+----+----+----+----+----------------------+
-| k | v1 | v2 | v3 | v4 | v5 |__DORIS_SEQUENCE_COL__|
-+---+----+----+----+----+----+----------------------+
-| 0 | 0  | 0  | 0  | 0  | 0  | 0                    |
-| 1 | 1  | 1  | 1  | 1  | 10 | 10                   |
-| 2 | 2  | 2  | 2  | 2  | 20 | 20                   |
-| 3 | 3  | 3  | 3  | 3  | 30 | 30                   |
-| 4 | 4  | 4  | 4  | 4  | 40 | 40                   |
-| 5 | 5  | 5  | 5  | 5  | 50 | 50                   |
-+---+----+----+----+----+----+----------------------+
-```
-
-通过灵活列更新导入如下数据:
-```json
-{"k": 1, "v1": 111, "v5": 9, "__DORIS_SEQUENCE_COL__": 9}
-{"k": 2, "v2": 222, "v5": 25, "__DORIS_SEQUENCE_COL__": 25}
-{"k": 3, "v3": 333}
-{"k": 4, "v4": 444, "v5": 50, "v1": 411, "v3": 433, "v2": null, 
"__DORIS_SEQUENCE_COL__": 50}
-{"k": 5, "v5": null, "__DORIS_SEQUENCE_COL__": null}
-{"k": 6, "v1": 611, "v3": 633}
-{"k": 7, "v3": 733, "v5": 300, "__DORIS_SEQUENCE_COL__": 300}
-```
-
-最终表中的数据如下:
-```sql
-+---+--------+--------+-----+------+--------+
-| k | v1     | v2     | v3  | v4   | v5     |
-+---+--------+--------+-----+------+--------+
-| 0 | 0      | 0      | 0   | 0    | 0      |
-| 1 | 1      | 1      | 1   | 1    | 1      |
-| 5 | 5      | 5      | 5   | 5    | 5      |
-| 2 | 2      | 222    | 2   | 2    | 25     |
-| 3 | 3      | 3      | 333 | 3    | 3      |
-| 4 | 411    | <null> | 433 | 444  | 50     |
-| 6 | 611    | 9876   | 633 | 1234 | <null> |
-| 7 | <null> | 9876   | 733 | 1234 | 300    |
-+---+--------+--------+-----+------+--------+
-```
-
-4. 当目标表的表属性中设置了 `function_column.sequence_col` 这一属性时,灵活列更新导入数据的 json 对象中 Key 为 
`__DORIS_SEQUENCE_COL__` 的键值对将被忽略,导入中某一行 `__DORIS_SEQUENCE_COL__` 列的值将与这一行中表属性 
`function_column.sequence_col` 所指定的列最终的值完全一致。
-
-例如,对于下表:
-```sql
-CREATE TABLE t3 (
-  `k` int(11) NULL, 
-  `v1` BIGINT NULL,
-  `v2` BIGINT NULL DEFAULT "9876",
-  `v3` BIGINT NOT NULL,
-  `v4` BIGINT NOT NULL DEFAULT "1234",
-  `v5` BIGINT NULL DEFAULT "31"
-) UNIQUE KEY(`k`) DISTRIBUTED BY HASH(`k`) BUCKETS 1
-PROPERTIES(
-"replication_num" = "3",
-"enable_unique_key_merge_on_write" = "true",
-"enable_unique_key_skip_bitmap_column" = "true",
-"function_column.sequence_col" = "v5");
-```
-
-表中有如下原始数据:
-```sql
-+---+----+----+----+----+----+----------------------+
-| k | v1 | v2 | v3 | v4 | v5 |__DORIS_SEQUENCE_COL__|
-+---+----+----+----+----+----+----------------------+
-| 0 | 0  | 0  | 0  | 0  | 0  | 0                    |
-| 1 | 1  | 1  | 1  | 1  | 10 | 10                   |
-| 2 | 2  | 2  | 2  | 2  | 20 | 20                   |
-| 3 | 3  | 3  | 3  | 3  | 30 | 30                   |
-| 4 | 4  | 4  | 4  | 4  | 40 | 40                   |
-| 5 | 5  | 5  | 5  | 5  | 50 | 50                   |
-+---+----+----+----+----+----+----------------------+
-```
-
-通过灵活列更新导入如下数据:
-```json
-{"k": 1, "v1": 111, "v5": 9}
-{"k": 2, "v2": 222, "v5": 25}
-{"k": 3, "v3": 333}
-{"k": 4, "v4": 444, "v5": 50, "v1": 411, "v3": 433, "v2": null}
-{"k": 5, "v5": null}
-{"k": 6, "v1": 611, "v3": 633}
-{"k": 7, "v3": 733, "v5": 300}
-```
-
-最终表中的数据如下:
-```sql
-+---+--------+--------+-----+------+-----+
-| k | v1     | v2     | v3  | v4   | v5  |
-+---+--------+--------+-----+------+-----+
-| 0 | 0      | 0      | 0   | 0    | 0   |
-| 1 | 1      | 1      | 1   | 1    | 10  |
-| 5 | 5      | 5      | 5   | 5    | 50  |
-| 2 | 2      | 222    | 2   | 2    | 25  |
-| 3 | 3      | 3      | 333 | 3    | 30  |
-| 4 | 411    | <null> | 433 | 444  | 50  |
-| 6 | 611    | 9876   | 633 | 1234 | 31  |
-| 7 | <null> | 9876   | 733 | 1234 | 300 |
-+---+--------+--------+-----+------+-----+
-```
-
-5. 使用灵活列更新时不能指定或开启如下一些导入属参数:
-    - 不能指定 `merge_type` 参数
-    - 不能指定 `delete` 参数
-    - 不能开启 `fuzzy_parse` 参数
-    - 不能指定 `columns` 参数
-    - 不能指定 `jsonpaths` 参数
-    - 不能指定 `hidden_columns` 参数
-    - 不能指定 `function_column.sequence_col` 参数
-    - 不能指定 `sql` 参数
-    - 不能开启 `memtable_on_sink_node` 前移
-    - 不能指定 `group_commit` 参数
-    - 不能指定 `where` 参数
-
-6. 不支持在有 Variant 列的表上进行灵活列更新。
-
-7. 不支持在有同步物化视图的表上进行灵活列更新。
+关于主键模型(Unique Key 
Model)表的列更新详细说明,包括使用示例、灵活部分列更新和新行处理等内容,请参考[列更新](./partial-column-update.md#主键模型的列更新)文档。
diff --git 
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-3.x/data-operate/update/update-overview.md
 
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-3.x/data-operate/update/update-overview.md
index 40970c3f400..139d2a0313d 100644
--- 
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-3.x/data-operate/update/update-overview.md
+++ 
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-3.x/data-operate/update/update-overview.md
@@ -34,7 +34,7 @@ Doris 提供了两大类数据更新方法:**通过数据导入进行更新**
 
 ![img](/images/update-overview/update-by-loading.png)
 
-1.2.2. 通过 `UPDATE` DML语句更新
+#### 1.2.2. 通过 `UPDATE` DML语句更新
 
 Doris 支持标准的 SQL `UPDATE` 语句,允许用户根据 `WHERE` 
子句指定的条件对数据进行更新。这种方式非常灵活,支持复杂的更新逻辑,例如跨表关联更新。
 
@@ -53,7 +53,7 @@ WHERE t1.user_id = t2.user_id;
 
 **注意**:`UPDATE` 语句的执行过程是先扫描满足条件的数据,然后将更新后的数据重新写回表中。它适合低频、批量的更新任务。**不建议对** 
**`UPDATE`** **语句进行高并发操作**,因为并发的 `UPDATE` 在涉及相同主键时,无法保证数据的隔离性。
 
-#### 1.2.2. 通过 `INSERT INTO SELECT` DML语句更新
+#### 1.2.3. 通过 `INSERT INTO SELECT` DML语句更新
 
 由于Doris默认提供了UPSERT的语义,因此使用`INSERT INTO SELECT`也可以实现类似于`UPDATE`的更新效果。
 
diff --git 
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-4.x/data-operate/update/update-of-unique-model.md
 
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-4.x/data-operate/update/partial-column-update.md
similarity index 67%
copy from 
i18n/zh-CN/docusaurus-plugin-content-docs/version-4.x/data-operate/update/update-of-unique-model.md
copy to 
i18n/zh-CN/docusaurus-plugin-content-docs/version-4.x/data-operate/update/partial-column-update.md
index 141c568b8e2..96abe0468d4 100644
--- 
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-4.x/data-operate/update/update-of-unique-model.md
+++ 
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-4.x/data-operate/update/partial-column-update.md
@@ -1,20 +1,26 @@
 ---
 {
-    "title": "主键模型的导入更新",
+    "title": "列更新",
     "language": "zh-CN",
-    "description": "这篇文档主要介绍 Doris 主键模型基于导入的更新。"
+    "description": "这篇文档介绍如何在 Doris 中对主键模型和聚合模型表进行列更新。"
 }
 ---
 
-这篇文档主要介绍 Doris 主键模型基于导入的更新。
+部分列更新允许您更新表中的特定字段,而不需要修改所有字段。这篇文档介绍如何对主键模型(Unique Key Model)和聚合模型(Aggregate 
Key Model)表进行部分列更新。
 
-## 整行更新
+## 概述
 
-使用 Doris 支持的 Stream Load、Broker Load、Routine Load、Insert Into 
等导入方式,向主键模型(Unique 模型)导入数据时,如果没有相应主键的数据行,则插入新数据;如果有相应主键的数据行,则进行更新。也就是说,Doris 
主键模型的导入是一种“upsert”模式。基于导入,对已有记录的更新,默认和导入一个新记录是完全一样的,因此可以参考数据导入的文档部分。
+部分列更新是指直接更新表中某些字段值,而不是全部字段值。可以使用 Update 语句进行更新,这种 Update 
语句通常先读取整行数据,然后更新部分字段值,再写回。这种读写事务非常耗时,不适合大批量数据写入。Doris 
在主键模型的导入更新中,提供了直接插入或更新部分列数据的功能,不需要先读取整行数据,从而大幅提升更新效率。
 
-## 部分列更新
+部分列更新特别适用于:
 
-部分列更新是指直接更新表中某些字段值,而不是全部字段值。可以使用 Update 语句进行更新,这种 Update 
语句通常先读取整行数据,然后更新部分字段值,再写回。这种读写事务非常耗时,不适合大批量数据写入。Doris 
在主键模型的导入更新中,提供了直接插入或更新部分列数据的功能,不需要先读取整行数据,从而大幅提升更新效率。
+- 
实时动态列更新,需要在表中实时高频更新某些字段值。例如用户标签表中有一些关于用户最新行为信息的字段需要实时更新,以便广告/推荐系统能够据此进行实时分析和决策。
+- 将多张源表拼接成一张大宽表。
+- 数据修正。
+
+## 主键模型的列更新
+
+Doris 在主键模型的导入更新中,提供了直接插入或更新部分列数据的功能,不需要先读取整行数据,从而大幅提升更新效率。
 
 :::caution 注意
 
@@ -24,15 +30,9 @@
 4. 不支持在进行 Schema Change 的表上进行部分列更新。
 :::
 
-### 适用场景
-
-- 
实时动态列更新,需要在表中实时高频更新某些字段值。例如用户标签表中有一些关于用户最新行为信息的字段需要实时更新,以便广告/推荐系统能够据此进行实时分析和决策。
-- 将多张源表拼接成一张大宽表。
-- 数据修正。
-
 ### 使用示例
 
-假设 Doris 中存在一张订单表 order_tbl,其中订单 id 是 Key 列,订单状态和订单金额是 Value 列。数据状态如下:
+假设 Doris 中存在一张订单表 `order_tbl`,其中订单 id 是 Key 列,订单状态和订单金额是 Value 列。数据状态如下:
 
 | 订单 id | 订单金额 | 订单状态 |
 | ------ | -------- | -------- |
@@ -49,9 +49,9 @@
 
 此时,用户点击付款后,Doris 系统需要将订单 id 为 '1' 的订单状态变更为 '待发货'。
 
-#### 可以使用以下导入方式进行部分列更新
+### 使用导入方式进行部分列更新
 
-**StreamLoad/BrokerLoad/RoutineLoad**
+#### StreamLoad/BrokerLoad/RoutineLoad
 
 准备如下 csv 文件:
 
@@ -71,7 +71,7 @@ partial_columns:true
 curl --location-trusted -u root: -H "partial_columns:true" -H 
"column_separator:," -H "columns:order_id,order_status" -T /tmp/update.csv 
http://127.0.0.1:8030/api/db1/order_tbl/_stream_load
 ```
 
-**INSERT INTO**
+#### INSERT INTO
 
 在所有数据模型中,`INSERT INTO` 给定部分列时默认行为是整行写入。为了防止误用,在 Merge-on-Write 实现中,`INSERT 
INTO` 默认仍然保持整行 UPSERT 的语义。如果需要开启部分列更新的语义,需要设置如下 session variable:
 
@@ -82,7 +82,7 @@ INSERT INTO order_tbl (order_id, order_status) VALUES (1, 
'待发货');
 
 需要注意的是,控制 insert 语句是否开启严格模式的会话变量 `enable_insert_strict` 的默认值为 true,即 insert 
语句默认开启严格模式。在严格模式下进行部分列更新不允许更新不存在的 key。所以,在使用 insert 语句进行部分列更新时,如果希望能插入不存在的 
key,需要在 `enable_unique_key_partial_update` 设置为 true 的基础上,同时将 
`enable_insert_strict` 设置为 false。
 
-**Flink Connector**
+#### Flink Connector
 
 如果使用 Flink Connector,需要添加如下配置:
 
@@ -92,7 +92,7 @@ INSERT INTO order_tbl (order_id, order_status) VALUES (1, 
'待发货');
 
 同时在 `sink.properties.column` 中指定要导入的列(必须包含所有 key 列,否则无法更新)。
 
-#### 更新结果
+### 更新结果
 
 更新后结果如下:
 
@@ -120,7 +120,7 @@ INSERT INTO order_tbl (order_id, order_status) VALUES (1, 
'待发货');
 
 目前,同一批次数据写入任务(无论是导入任务还是 `INSERT INTO`)的所有行只能更新相同的列。如果需要更新不同列的数据,则需要分不同批次进行写入。
 
-## 灵活部分列更新
+### 灵活部分列更新
 
 此前,doris 支持的部分列更新功能限制了一次导入中每一行必须更新相同的列。现在,doris 
支持一种更加灵活的更新方式,它使得一次导入中的每一行可以更新不同的列(3.1.0版本及以上支持)。
 
@@ -130,15 +130,15 @@ INSERT INTO order_tbl (order_id, order_status) VALUES (1, 
'待发货');
 2. 在使用灵活列更新时导入文件必须为 json 格式的数据
 :::
 
-### 适用场景
+#### 适用场景
 
 在使用 CDC 的方式将某个数据系统的数据实时同步到 Doris 
中时,源端系统输出的记录可能并不是完整的行数据,而是只有主键和被更新的列的数据。在这种情况下,某个时间窗口内的一批数据中每一行更新的列可能都是不同的。此时,可以使用灵活列更新的方式来将数据导入到
 Doris 中。
 
-### 使用方式
+#### 使用方式
 
 **存量表开启灵活列更新功能**
 
-对于在旧版本 Doris 中已经建好的存量 Merge-On-Write 表,在升级 Doris 之后如果想要使用灵活列更新的功能,可以使用 `ALTER 
TALBE db1.tbl1 ENABLE FEATURE "UPDATE_FLEXIBLE_COLUMNS";` 来开启这一功能。执行完上述语句后使用 
`show create table db1.tbl1` 的结果中如果包含 `"enable_unique_key_skip_bitmap_column" = 
"true"` 则表示功能开启成功。注意,使用这一方式之前需要确保目标表已经开启了 light-schema-change 的功能。
+对于在旧版本 Doris 中已经建好的存量 Merge-On-Write 表,在升级 Doris 之后如果想要使用灵活列更新的功能,可以使用 `ALTER 
TABLE db1.tbl1 ENABLE FEATURE "UPDATE_FLEXIBLE_COLUMNS";` 来开启这一功能。执行完上述语句后使用 
`show create table db1.tbl1` 的结果中如果包含 `"enable_unique_key_skip_bitmap_column" = 
"true"` 则表示功能开启成功。注意,使用这一方式之前需要确保目标表已经开启了 light-schema-change 的功能。
 
 **新建表使用灵活列更新功能**
 
@@ -165,7 +165,7 @@ unique_key_update_mode:UPDATE_FLEXIBLE_COLUMNS
 'sink.properties.unique_key_update_mode' = 'UPDATE_FLEXIBLE_COLUMNS'
 ```
 
-### 示例
+#### 示例
 
 假设有如下表
 
@@ -242,131 +242,15 @@ MySQL [email protected]:d1> select * from t1;
 +---+-----+------+-----+------+--------+
 ```
 
-### 限制与注意事项
+#### 限制与注意事项
 
 1. 和之前的部分列更新相同,灵活列更新要求导入的每一行数据需要包括所有的 Key 列,不满足这一要求的行数据将被过滤掉,同时计入 `filter 
rows` 的计数中,如果 `filtered rows` 的数量超过了本次导入 `max_filter_ratio` 
所能容忍的上限,则整个导入将会失败。同时,被过滤的数据会在 error log 留下一条日志。
 
 2. 灵活列更新导入中每一个 json 对象中的键值对只有当它的 Key 
和目标表中某一列的列名一致时才是有效的,不满足这一要求的键值对将被忽略。同时,Key 为 
`__DORIS_VERSION_COL__`/`__DORIS_ROW_STORE_COL__`/`__DORIS_SKIP_BITMAP_COL__` 
的键值对也将被忽略。
 
-3. 当目标表的表属性中设置了 `function_column.sequence_type` 这一属性时,灵活列更新的导入可以通过在 json 对象中包括 
Key 为 `__DORIS_SEQUENCE_COL__` 的键值对来指定目标表中 `__DORIS_SEQUENCE_COL__` 列的值。对于不指定 
`__DORIS_SEQUENCE_COL__` 列的值的行,如果这一行的 Key 在原表中存在,则这一行 `__DORIS_SEQUENCE_COL__` 
列的值将被填充为旧行中对应的值,否则该列的值将被填充为 `null` 值
-
-例如,对于下表:
-```sql
-CREATE TABLE t2 (
-  `k` int(11) NULL, 
-  `v1` BIGINT NULL,
-  `v2` BIGINT NULL DEFAULT "9876",
-  `v3` BIGINT NOT NULL,
-  `v4` BIGINT NOT NULL DEFAULT "1234",
-  `v5` BIGINT NULL
-) UNIQUE KEY(`k`) DISTRIBUTED BY HASH(`k`) BUCKETS 1
-PROPERTIES(
-"replication_num" = "3",
-"enable_unique_key_merge_on_write" = "true",
-"enable_unique_key_skip_bitmap_column" = "true",
-"function_column.sequence_type" = "int");
-```
-
-表中有如下原始数据:
-```sql
-+---+----+----+----+----+----+----------------------+
-| k | v1 | v2 | v3 | v4 | v5 |__DORIS_SEQUENCE_COL__|
-+---+----+----+----+----+----+----------------------+
-| 0 | 0  | 0  | 0  | 0  | 0  | 0                    |
-| 1 | 1  | 1  | 1  | 1  | 10 | 10                   |
-| 2 | 2  | 2  | 2  | 2  | 20 | 20                   |
-| 3 | 3  | 3  | 3  | 3  | 30 | 30                   |
-| 4 | 4  | 4  | 4  | 4  | 40 | 40                   |
-| 5 | 5  | 5  | 5  | 5  | 50 | 50                   |
-+---+----+----+----+----+----+----------------------+
-```
-
-通过灵活列更新导入如下数据:
-```json
-{"k": 1, "v1": 111, "v5": 9, "__DORIS_SEQUENCE_COL__": 9}
-{"k": 2, "v2": 222, "v5": 25, "__DORIS_SEQUENCE_COL__": 25}
-{"k": 3, "v3": 333}
-{"k": 4, "v4": 444, "v5": 50, "v1": 411, "v3": 433, "v2": null, 
"__DORIS_SEQUENCE_COL__": 50}
-{"k": 5, "v5": null, "__DORIS_SEQUENCE_COL__": null}
-{"k": 6, "v1": 611, "v3": 633}
-{"k": 7, "v3": 733, "v5": 300, "__DORIS_SEQUENCE_COL__": 300}
-```
-
-最终表中的数据如下:
-```sql
-+---+--------+--------+-----+------+--------+
-| k | v1     | v2     | v3  | v4   | v5     |
-+---+--------+--------+-----+------+--------+
-| 0 | 0      | 0      | 0   | 0    | 0      |
-| 1 | 1      | 1      | 1   | 1    | 1      |
-| 5 | 5      | 5      | 5   | 5    | 5      |
-| 2 | 2      | 222    | 2   | 2    | 25     |
-| 3 | 3      | 3      | 333 | 3    | 3      |
-| 4 | 411    | <null> | 433 | 444  | 50     |
-| 6 | 611    | 9876   | 633 | 1234 | <null> |
-| 7 | <null> | 9876   | 733 | 1234 | 300    |
-+---+--------+--------+-----+------+--------+
-```
-
-4. 当目标表的表属性中设置了 `function_column.sequence_col` 这一属性时,灵活列更新导入数据的 json 对象中 Key 为 
`__DORIS_SEQUENCE_COL__` 的键值对将被忽略,导入中某一行 `__DORIS_SEQUENCE_COL__` 列的值将与这一行中表属性 
`function_column.sequence_col` 所指定的列最终的值完全一致。
-
-例如,对于下表:
-```sql
-CREATE TABLE t3 (
-  `k` int(11) NULL, 
-  `v1` BIGINT NULL,
-  `v2` BIGINT NULL DEFAULT "9876",
-  `v3` BIGINT NOT NULL,
-  `v4` BIGINT NOT NULL DEFAULT "1234",
-  `v5` BIGINT NULL DEFAULT "31"
-) UNIQUE KEY(`k`) DISTRIBUTED BY HASH(`k`) BUCKETS 1
-PROPERTIES(
-"replication_num" = "3",
-"enable_unique_key_merge_on_write" = "true",
-"enable_unique_key_skip_bitmap_column" = "true",
-"function_column.sequence_col" = "v5");
-```
-
-表中有如下原始数据:
-```sql
-+---+----+----+----+----+----+----------------------+
-| k | v1 | v2 | v3 | v4 | v5 |__DORIS_SEQUENCE_COL__|
-+---+----+----+----+----+----+----------------------+
-| 0 | 0  | 0  | 0  | 0  | 0  | 0                    |
-| 1 | 1  | 1  | 1  | 1  | 10 | 10                   |
-| 2 | 2  | 2  | 2  | 2  | 20 | 20                   |
-| 3 | 3  | 3  | 3  | 3  | 30 | 30                   |
-| 4 | 4  | 4  | 4  | 4  | 40 | 40                   |
-| 5 | 5  | 5  | 5  | 5  | 50 | 50                   |
-+---+----+----+----+----+----+----------------------+
-```
-
-通过灵活列更新导入如下数据:
-```json
-{"k": 1, "v1": 111, "v5": 9}
-{"k": 2, "v2": 222, "v5": 25}
-{"k": 3, "v3": 333}
-{"k": 4, "v4": 444, "v5": 50, "v1": 411, "v3": 433, "v2": null}
-{"k": 5, "v5": null}
-{"k": 6, "v1": 611, "v3": 633}
-{"k": 7, "v3": 733, "v5": 300}
-```
+3. 不支持在有 Variant 列的表上进行灵活列更新。
 
-最终表中的数据如下:
-```sql
-+---+--------+--------+-----+------+-----+
-| k | v1     | v2     | v3  | v4   | v5  |
-+---+--------+--------+-----+------+-----+
-| 0 | 0      | 0      | 0   | 0    | 0   |
-| 1 | 1      | 1      | 1   | 1    | 10  |
-| 5 | 5      | 5      | 5   | 5    | 50  |
-| 2 | 2      | 222    | 2   | 2    | 25  |
-| 3 | 3      | 3      | 333 | 3    | 30  |
-| 4 | 411    | <null> | 433 | 444  | 50  |
-| 6 | 611    | 9876   | 633 | 1234 | 31  |
-| 7 | <null> | 9876   | 733 | 1234 | 300 |
-+---+--------+--------+-----+------+-----+
-```
+4. 不支持在有同步物化视图的表上进行灵活列更新。
 
 5. 使用灵活列更新时不能指定或开启如下一些导入属参数:
     - 不能指定 `merge_type` 参数
@@ -381,12 +265,7 @@ PROPERTIES(
     - 不能指定 `group_commit` 参数
     - 不能指定 `where` 参数
 
-6. 不支持在有 Variant 列的表上进行灵活列更新。
-
-7. 不支持在有同步物化视图的表上进行灵活列更新。
-
-
-## 部分列更新/灵活列更新中对新插入的行的处理
+### 部分列更新/灵活列更新中对新插入的行的处理
 
 session variable或导入属性`partial_update_new_key_behavior`用于控制部分列更新和灵活列更新中插入的新行的行为。
 
@@ -455,3 +334,53 @@ mysql> select * from user_profile;
 +------+-------+------+----------+---------+---------------------+
 ```
 
+## 聚合模型的列更新
+
+Aggregate 表主要在预聚合场景使用而非数据更新的场景使用,但也可以通过将聚合函数设置为 REPLACE_IF_NOT_NULL 来实现部分列更新效果。
+
+### 建表
+
+将需要进行列更新的字段对应的聚合函数设置为`REPLACE_IF_NOT_NULL`
+
+```sql
+CREATE TABLE order_tbl (
+  order_id int(11) NULL,
+  order_amount int(11) REPLACE_IF_NOT_NULL NULL,
+  order_status varchar(100) REPLACE_IF_NOT_NULL NULL
+) ENGINE=OLAP
+AGGREGATE KEY(order_id)
+COMMENT 'OLAP'
+DISTRIBUTED BY HASH(order_id) BUCKETS 1
+PROPERTIES (
+"replication_allocation" = "tag.location.default: 1"
+);
+```
+
+### 数据写入
+
+无论是 Stream Load、Broker Load、Routine Load 还是`INSERT INTO`, 直接写入要更新的字段的数据即可
+
+### 示例
+
+与前面例子相同,对应的 Stream Load 命令为(不需要额外的 header):
+
+```shell
+$ cat update.csv
+
+1,待发货
+
+curl  --location-trusted -u root: -H "column_separator:," -H 
"columns:order_id,order_status" -T ./update.csv 
http://127.0.0.1:8030/api/db1/order_tbl/_stream_load
+```
+
+对应的`INSERT INTO`语句为(不需要额外设置 session variable):
+
+```sql
+INSERT INTO order_tbl (order_id, order_status) values (1,'待发货');
+```
+
+### 部分列更新使用注意
+
+Aggregate Key 
模型在写入过程中不做任何额外处理,所以写入性能不受影响,与普通的数据导入相同。但是在查询时进行聚合的代价较大,典型的聚合查询性能相比 Unique Key 
模型的 Merge-on-Write 实现会有 5-10 倍的下降。
+
+由于 `REPLACE_IF_NOT_NULL` 聚合函数仅在非 NULL 值时才会生效,因此用户无法将某个字段值修改为 NULL 值。
+
diff --git 
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-4.x/data-operate/update/unique-update-sql.md
 
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-4.x/data-operate/update/unique-update-sql.md
new file mode 100644
index 00000000000..67ff892679e
--- /dev/null
+++ 
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-4.x/data-operate/update/unique-update-sql.md
@@ -0,0 +1,123 @@
+---
+{
+    "title": "使用 UPDATE 命令更新数据",
+    "language": "zh-CN",
+    "description": "这篇文档介绍如何在 Doris 中使用 UPDATE 命令修改数据。"
+}
+---
+
+这篇文档介绍如何在 Doris 中使用 `UPDATE` 命令修改数据。`UPDATE` 命令仅适用于主键模型(Unique Key Model)表。
+
+## 适用场景
+
+- 小规模数据更新:适用于需要修正少量数据的场景,例如修正某些记录中的错误字段,或更新特定字段的状态(如订单状态更新)。
+
+- 某些字段的 ETL 批量处理:适用于对某个字段进行大规模更新的场景,常见于 ETL 处理场景。注意:大规模数据更新应该是不频繁的。
+
+## 工作原理
+
+查询引擎使用自身的过滤逻辑来识别需要更新的行。然后,使用主键模型的 Value 
列逻辑,用新数据替换旧数据。需要更新的行被修改后重新插入到表中,以实现行级更新。
+
+### 同步性
+
+Doris 中的 `UPDATE` 语法是同步的,这意味着一旦 `UPDATE` 语句成功执行,更新操作就已完成,数据立即可见。
+
+### 性能
+
+`UPDATE` 语句的性能与需要更新的行数和查询条件的效率密切相关。
+
+- 需要更新的行数:需要更新的行数越多,`UPDATE` 语句的执行速度就越慢。对于小规模更新,Doris 支持与 `INSERT INTO` 
语句相似的频率。对于大规模更新,由于执行时间较长,仅适用于不频繁的调用。
+
+- 查询条件的效率:`UPDATE` 实现首先读取满足查询条件的行。因此,如果查询条件高效,`UPDATE` 
速度就会快。理想情况下,条件列应该命中索引或分区桶裁剪,这样 Doris 
就不需要扫描整个表,可以快速定位需要更新的行,从而提高更新效率。强烈建议不要在条件列中包含值列。
+
+## 使用示例
+
+假设在金融风控场景中存在一张交易明细表,结构如下:
+
+```sql
+CREATE TABLE transaction_details (
+  transaction_id BIGINT NOT NULL,        -- 唯一交易 ID
+  user_id BIGINT NOT NULL,               -- 用户 ID
+  transaction_date DATE NOT NULL,        -- 交易日期
+  transaction_time DATETIME NOT NULL,    -- 交易时间
+  transaction_amount DECIMAL(18, 2),     -- 交易金额
+  transaction_device STRING,             -- 交易设备
+  transaction_region STRING,             -- 交易地区
+  average_daily_amount DECIMAL(18, 2),   -- 最近 3 个月的平均日交易金额
+  recent_transaction_count INT,          -- 最近 7 天的交易次数
+  has_dispute_history BOOLEAN,           -- 是否有争议历史
+  risk_level STRING                      -- 风险等级
+)
+UNIQUE KEY(transaction_id)
+DISTRIBUTED BY HASH(transaction_id) BUCKETS 16
+PROPERTIES (
+  "replication_num" = "3",               -- 副本数,默认为 3
+  "enable_unique_key_merge_on_write" = "true"  -- 启用 MOW 模式,支持合并更新
+);
+```
+
+存在以下交易数据:
+
+```sql
++----------------+---------+------------------+---------------------+--------------------+--------------------+--------------------+----------------------+--------------------------+---------------------+------------+
+| transaction_id | user_id | transaction_date | transaction_time    | 
transaction_amount | transaction_device | transaction_region | 
average_daily_amount | recent_transaction_count | has_dispute_history | 
risk_level |
++----------------+---------+------------------+---------------------+--------------------+--------------------+--------------------+----------------------+--------------------------+---------------------+------------+
+|           1001 |    5001 | 2024-11-24       | 2024-11-24 14:30:00 |          
   100.00 | iPhone 12          | New York           |               100.00 |    
                   10 |                   0 | NULL       |
+|           1002 |    5002 | 2024-11-24       | 2024-11-24 03:30:00 |          
   120.00 | iPhone 12          | New York           |               100.00 |    
                   15 |                   0 | NULL       |
+|           1003 |    5003 | 2024-11-24       | 2024-11-24 10:00:00 |          
   150.00 | Samsung S21        | Los Angeles        |               100.00 |    
                   30 |                   0 | NULL       |
+|           1004 |    5004 | 2024-11-24       | 2024-11-24 16:00:00 |          
   300.00 | MacBook Pro        | high_risk_region1  |               200.00 |    
                    5 |                   0 | NULL       |
+|           1005 |    5005 | 2024-11-24       | 2024-11-24 11:00:00 |          
  1100.00 | iPad Pro           | Chicago            |               200.00 |    
                   10 |                   0 | NULL       |
++----------------+---------+------------------+---------------------+--------------------+--------------------+--------------------+----------------------+--------------------------+---------------------+------------+
+```
+
+根据以下风控规则更新所有当日交易记录的风险等级:
+1. 有争议历史的交易风险等级为 high。
+2. 高风险地区的交易风险等级为 high。
+3. 异常金额(超过日均金额 5 倍)的交易风险等级为 high。
+4. 最近 7 天频繁交易:
+   a. 交易次数 > 50 次的交易风险等级为 high。
+   b. 交易次数在 20 到 50 次之间的交易风险等级为 medium。
+5. 非工作时间(凌晨 2 点到 4 点)的交易风险等级为 medium。
+6. 默认风险等级为 low。
+
+```sql
+UPDATE transaction_details
+SET risk_level = CASE
+  -- 有争议历史或高风险地区的交易
+  WHEN has_dispute_history = TRUE THEN 'high'
+  WHEN transaction_region IN ('high_risk_region1', 'high_risk_region2') THEN 
'high'
+
+  -- 异常交易金额
+  WHEN transaction_amount > 5 * average_daily_amount THEN 'high'
+
+  -- 最近 7 天高频交易
+  WHEN recent_transaction_count > 50 THEN 'high'
+  WHEN recent_transaction_count BETWEEN 20 AND 50 THEN 'medium'
+
+  -- 非工作时间交易
+  WHEN HOUR(transaction_time) BETWEEN 2 AND 4 THEN 'medium'
+
+  -- 默认风险等级
+  ELSE 'low'
+END
+WHERE transaction_date = '2024-11-24';
+```
+
+更新后的数据如下:
+
+```sql
++----------------+---------+------------------+---------------------+--------------------+--------------------+--------------------+----------------------+--------------------------+---------------------+------------+
+| transaction_id | user_id | transaction_date | transaction_time    | 
transaction_amount | transaction_device | transaction_region | 
average_daily_amount | recent_transaction_count | has_dispute_history | 
risk_level |
++----------------+---------+------------------+---------------------+--------------------+--------------------+--------------------+----------------------+--------------------------+---------------------+------------+
+|           1001 |    5001 | 2024-11-24       | 2024-11-24 14:30:00 |          
   100.00 | iPhone 12          | New York           |               100.00 |    
                   10 |                   0 | low        |
+|           1002 |    5002 | 2024-11-24       | 2024-11-24 03:30:00 |          
   120.00 | iPhone 12          | New York           |               100.00 |    
                   15 |                   0 | medium     |
+|           1003 |    5003 | 2024-11-24       | 2024-11-24 10:00:00 |          
   150.00 | Samsung S21        | Los Angeles        |               100.00 |    
                   30 |                   0 | medium     |
+|           1004 |    5004 | 2024-11-24       | 2024-11-24 16:00:00 |          
   300.00 | MacBook Pro        | high_risk_region1  |               200.00 |    
                    5 |                   0 | high       |
+|           1005 |    5005 | 2024-11-24       | 2024-11-24 11:00:00 |          
  1100.00 | iPad Pro           | Chicago            |               200.00 |    
                   10 |                   0 | high       |
++----------------+---------+------------------+---------------------+--------------------+--------------------+--------------------+----------------------+--------------------------+---------------------+------------+
+```
+
+## 更多帮助
+
+有关数据更新的更详细语法,请参考 
[UPDATE](../../sql-manual/sql-statements/data-modification/DML/UPDATE) 
命令手册。您也可以在 MySQL 客户端命令行中输入 `HELP UPDATE` 获取更多帮助。
+
diff --git 
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-4.x/data-operate/update/update-of-aggregate-model.md
 
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-4.x/data-operate/update/update-of-aggregate-model.md
index 43db19b60ff..5914c6ae65f 100644
--- 
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-4.x/data-operate/update/update-of-aggregate-model.md
+++ 
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-4.x/data-operate/update/update-of-aggregate-model.md
@@ -12,52 +12,6 @@
 
 使用 Doris 支持的 Stream Load,Broker Load,Routine Load,Insert Into 等导入方式,往聚合模型(Agg 
模型)中进行数据导入时,都会将新的值与旧的聚合值,根据列的聚合函数产出新的聚合值,这个值可能是插入时产出,也可能是异步 Compaction 
时产出,但是用户查询时,都会得到一样的返回值。
 
-## 聚合模型的部分列更新
+## 部分列更新
 
-Aggregate 表主要在预聚合场景使用而非数据更新的场景使用,但也可以通过将聚合函数设置为 REPLACE_IF_NOT_NULL 来实现部分列更新效果。
-
-**建表**
-
-将需要进行列更新的字段对应的聚合函数设置为`REPLACE_IF_NOT_NULL`
-
-```sql
-CREATE TABLE order_tbl (
-  order_id int(11) NULL,
-  order_amount int(11) REPLACE_IF_NOT_NULL NULL,
-  order_status varchar(100) REPLACE_IF_NOT_NULL NULL
-) ENGINE=OLAP
-AGGREGATE KEY(order_id)
-COMMENT 'OLAP'
-DISTRIBUTED BY HASH(order_id) BUCKETS 1
-PROPERTIES (
-"replication_allocation" = "tag.location.default: 1"
-);
-```
-
-**数据写入**
-
-无论是 Stream Load、Broker Load、Routine Load 还是`INSERT INTO`, 直接写入要更新的字段的数据即可
-
-**示例**
-
-与前面例子相同,对应的 Stream Load 命令为(不需要额外的 header):
-
-```shell
-$ cat update.csv
-
-1,To be shipped
-
-curl  --location-trusted -u root: -H "column_separator:," -H 
"columns:order_id,order_status" -T /tmp/update.csv 
http://127.0.0.1:8030/api/db1/order_tbl/_stream_load
-```
-
-对应的`INSERT INTO`语句为(不需要额外设置 session variable):
-
-```sql
-INSERT INTO order_tbl (order_id, order_status) values (1,'待发货');
-```
-
-## 部分列更新使用注意
-
-Aggregate Key 
模型在写入过程中不做任何额外处理,所以写入性能不受影响,与普通的数据导入相同。但是在查询时进行聚合的代价较大,典型的聚合查询性能相比 Unique Key 
模型的 Merge-on-Write 实现会有 5-10 倍的下降。
-
-由于 `REPLACE_IF_NOT_NULL` 聚合函数仅在非 NULL 值时才会生效,因此用户无法将某个字段值修改为 NULL 值。
+关于聚合模型(Aggregate Key 
Model)表的列更新详细说明,包括建表、数据写入示例和使用注意事项等内容,请参考[列更新](./partial-column-update.md#聚合模型的列更新)文档。
diff --git 
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-4.x/data-operate/update/update-of-unique-model.md
 
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-4.x/data-operate/update/update-of-unique-model.md
index 141c568b8e2..9f85bfdb86e 100644
--- 
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-4.x/data-operate/update/update-of-unique-model.md
+++ 
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-4.x/data-operate/update/update-of-unique-model.md
@@ -10,448 +10,8 @@
 
 ## 整行更新
 
-使用 Doris 支持的 Stream Load、Broker Load、Routine Load、Insert Into 
等导入方式,向主键模型(Unique 模型)导入数据时,如果没有相应主键的数据行,则插入新数据;如果有相应主键的数据行,则进行更新。也就是说,Doris 
主键模型的导入是一种“upsert”模式。基于导入,对已有记录的更新,默认和导入一个新记录是完全一样的,因此可以参考数据导入的文档部分。
+使用 Doris 支持的 Stream Load、Broker Load、Routine Load、Insert Into 
等导入方式,向主键模型(Unique 模型)导入数据时,如果没有相应主键的数据行,则插入新数据;如果有相应主键的数据行,则进行更新。也就是说,Doris 
主键模型的导入是一种"upsert"模式。基于导入,对已有记录的更新,默认和导入一个新记录是完全一样的,因此可以参考数据导入的文档部分。
 
 ## 部分列更新
 
-部分列更新是指直接更新表中某些字段值,而不是全部字段值。可以使用 Update 语句进行更新,这种 Update 
语句通常先读取整行数据,然后更新部分字段值,再写回。这种读写事务非常耗时,不适合大批量数据写入。Doris 
在主键模型的导入更新中,提供了直接插入或更新部分列数据的功能,不需要先读取整行数据,从而大幅提升更新效率。
-
-:::caution 注意
-
-1. 2.0 版本仅在 Unique Key 的 Merge-on-Write 实现中支持部分列更新能力。
-2. 从 2.0.2 版本开始,支持使用 INSERT INTO 进行部分列更新。
-3. 不支持在有同步物化视图的表上进行部分列更新。
-4. 不支持在进行 Schema Change 的表上进行部分列更新。
-:::
-
-### 适用场景
-
-- 
实时动态列更新,需要在表中实时高频更新某些字段值。例如用户标签表中有一些关于用户最新行为信息的字段需要实时更新,以便广告/推荐系统能够据此进行实时分析和决策。
-- 将多张源表拼接成一张大宽表。
-- 数据修正。
-
-### 使用示例
-
-假设 Doris 中存在一张订单表 order_tbl,其中订单 id 是 Key 列,订单状态和订单金额是 Value 列。数据状态如下:
-
-| 订单 id | 订单金额 | 订单状态 |
-| ------ | -------- | -------- |
-| 1      | 100      | 待付款   |
-
-```sql
-+----------+--------------+--------------+
-| order_id | order_amount | order_status |
-+----------+--------------+--------------+
-| 1        |          100 | 待付款        |
-+----------+--------------+--------------+
-1 row in set (0.01 sec)
-```
-
-此时,用户点击付款后,Doris 系统需要将订单 id 为 '1' 的订单状态变更为 '待发货'。
-
-#### 可以使用以下导入方式进行部分列更新
-
-**StreamLoad/BrokerLoad/RoutineLoad**
-
-准备如下 csv 文件:
-
-```
-1,待发货
-```
-
-在导入时添加如下 header:
-
-```sql
-partial_columns:true
-```
-
-同时在 `columns` 中指定要导入的列(必须包含所有 key 列,否则无法更新)。下面是一个 Stream Load 的例子:
-
-```sql
-curl --location-trusted -u root: -H "partial_columns:true" -H 
"column_separator:," -H "columns:order_id,order_status" -T /tmp/update.csv 
http://127.0.0.1:8030/api/db1/order_tbl/_stream_load
-```
-
-**INSERT INTO**
-
-在所有数据模型中,`INSERT INTO` 给定部分列时默认行为是整行写入。为了防止误用,在 Merge-on-Write 实现中,`INSERT 
INTO` 默认仍然保持整行 UPSERT 的语义。如果需要开启部分列更新的语义,需要设置如下 session variable:
-
-```sql
-SET enable_unique_key_partial_update=true;
-INSERT INTO order_tbl (order_id, order_status) VALUES (1, '待发货');
-```
-
-需要注意的是,控制 insert 语句是否开启严格模式的会话变量 `enable_insert_strict` 的默认值为 true,即 insert 
语句默认开启严格模式。在严格模式下进行部分列更新不允许更新不存在的 key。所以,在使用 insert 语句进行部分列更新时,如果希望能插入不存在的 
key,需要在 `enable_unique_key_partial_update` 设置为 true 的基础上,同时将 
`enable_insert_strict` 设置为 false。
-
-**Flink Connector**
-
-如果使用 Flink Connector,需要添加如下配置:
-
-```sql
-'sink.properties.partial_columns' = 'true',
-```
-
-同时在 `sink.properties.column` 中指定要导入的列(必须包含所有 key 列,否则无法更新)。
-
-#### 更新结果
-
-更新后结果如下:
-
-```sql
-+----------+--------------+--------------+
-| order_id | order_amount | order_status |
-+----------+--------------+--------------+
-| 1        |          100 | 待发货        |
-+----------+--------------+--------------+
-1 row in set (0.01 sec)
-```
-
-### 使用注意
-
-由于 Merge-on-Write 实现需要在数据写入时进行整行数据的补齐,以保证最优的查询性能,因此使用 Merge-on-Write 
实现进行部分列更新会导致部分导入性能下降。
-
-写入性能优化建议:
-
-- 使用配备 NVMe 的 SSD,或者极速 SSD 云盘。因为补齐数据时会大量读取历史数据,产生较高的读 IOPS 以及读吞吐。
-- 开启行存能够大大减少补齐数据时产生的 IOPS,导入性能提升明显。用户可以在建表时通过如下 property 来开启行存:
-
-```Plain
-"store_row_column" = "true"
-```
-
-目前,同一批次数据写入任务(无论是导入任务还是 `INSERT INTO`)的所有行只能更新相同的列。如果需要更新不同列的数据,则需要分不同批次进行写入。
-
-## 灵活部分列更新
-
-此前,doris 支持的部分列更新功能限制了一次导入中每一行必须更新相同的列。现在,doris 
支持一种更加灵活的更新方式,它使得一次导入中的每一行可以更新不同的列(3.1.0版本及以上支持)。
-
-:::caution 注意:
-
-1. 目前只有 stream load 这一种导入方式以及使用 stream load 作为其导入方式的工具 (如 
doris-flink-connector) 支持灵活列更新功能
-2. 在使用灵活列更新时导入文件必须为 json 格式的数据
-:::
-
-### 适用场景
-
-在使用 CDC 的方式将某个数据系统的数据实时同步到 Doris 
中时,源端系统输出的记录可能并不是完整的行数据,而是只有主键和被更新的列的数据。在这种情况下,某个时间窗口内的一批数据中每一行更新的列可能都是不同的。此时,可以使用灵活列更新的方式来将数据导入到
 Doris 中。
-
-### 使用方式
-
-**存量表开启灵活列更新功能**
-
-对于在旧版本 Doris 中已经建好的存量 Merge-On-Write 表,在升级 Doris 之后如果想要使用灵活列更新的功能,可以使用 `ALTER 
TALBE db1.tbl1 ENABLE FEATURE "UPDATE_FLEXIBLE_COLUMNS";` 来开启这一功能。执行完上述语句后使用 
`show create table db1.tbl1` 的结果中如果包含 `"enable_unique_key_skip_bitmap_column" = 
"true"` 则表示功能开启成功。注意,使用这一方式之前需要确保目标表已经开启了 light-schema-change 的功能。
-
-**新建表使用灵活列更新功能**
-
-对于新建的表,如果需要使用灵活列更新功能,建表时需要指定如下表属性,以开启 Merge-on-Write 实现,同时使得表具有灵活列更新所需要的 
`bitmap` 隐藏列。
-
-```Plain
-"enable_unique_key_merge_on_write" = "true"
-"enable_unique_key_skip_bitmap_column" = "true"
-```
-
-**StreamLoad**
-
-在使用 Stream Load 导入时添加如下 header
-
-```Plain
-unique_key_update_mode:UPDATE_FLEXIBLE_COLUMNS
-```
-
-**Flink Doris Connector**
-
-如果使用 Flink Doris Connector, 需要添加如下配置:
-
-```Plain
-'sink.properties.unique_key_update_mode' = 'UPDATE_FLEXIBLE_COLUMNS'
-```
-
-### 示例
-
-假设有如下表
-
-```sql
-CREATE TABLE t1 (
-  `k` int(11) NULL, 
-  `v1` BIGINT NULL,
-  `v2` BIGINT NULL DEFAULT "9876",
-  `v3` BIGINT NOT NULL,
-  `v4` BIGINT NOT NULL DEFAULT "1234",
-  `v5` BIGINT NULL
-) UNIQUE KEY(`k`) DISTRIBUTED BY HASH(`k`) BUCKETS 1
-PROPERTIES(
-"replication_num" = "3",
-"enable_unique_key_merge_on_write" = "true",
-"enable_unique_key_skip_bitmap_column" = "true");
-```
-
-表中有如下原始数据
-
-```sql
-MySQL [email protected]:d1> select * from t1;
-+---+----+----+----+----+----+
-| k | v1 | v2 | v3 | v4 | v5 |
-+---+----+----+----+----+----+
-| 0 | 0  | 0  | 0  | 0  | 0  |
-| 1 | 1  | 1  | 1  | 1  | 1  |
-| 2 | 2  | 2  | 2  | 2  | 2  |
-| 3 | 3  | 3  | 3  | 3  | 3  |
-| 4 | 4  | 4  | 4  | 4  | 4  |
-| 5 | 5  | 5  | 5  | 5  | 5  |
-+---+----+----+----+----+----+
-```
-
-现在通过灵活列更新导入来更新其中的一些行的字段
-
-```shell
-$ cat test1.json
-```
-```json
-{"k": 0, "__DORIS_DELETE_SIGN__": 1}
-{"k": 1, "v1": 10}
-{"k": 2, "v2": 20, "v5": 25}
-{"k": 3, "v3": 30}
-{"k": 4, "v4": 20, "v1": 43, "v3": 99}
-{"k": 5, "v5": null}
-{"k": 6, "v1": 999, "v3": 777}
-{"k": 2, "v4": 222}
-{"k": 1, "v2": 111, "v3": 111}
-```
-```shell
-curl --location-trusted -u root: \
--H "strict_mode:false" \
--H "format:json" \
--H "read_json_by_line:true" \
--H "unique_key_update_mode:UPDATE_FLEXIBLE_COLUMNS" \
--T test1.json \
--XPUT http://<host>:<http_port>/api/d1/t1/_stream_load
-```
-
-更新后表中的数据如下:
-
-```sql
-MySQL [email protected]:d1> select * from t1;
-+---+-----+------+-----+------+--------+
-| k | v1  | v2   | v3  | v4   | v5     |
-+---+-----+------+-----+------+--------+
-| 1 | 10  | 111  | 111 | 1    | 1      |
-| 2 | 2   | 20   | 2   | 222  | 25     |
-| 3 | 3   | 3    | 30  | 3    | 3      |
-| 4 | 43  | 4    | 99  | 20   | 4      |
-| 5 | 5   | 5    | 5   | 5    | <null> |
-| 6 | 999 | 9876 | 777 | 1234 | <null> |
-+---+-----+------+-----+------+--------+
-```
-
-### 限制与注意事项
-
-1. 和之前的部分列更新相同,灵活列更新要求导入的每一行数据需要包括所有的 Key 列,不满足这一要求的行数据将被过滤掉,同时计入 `filter 
rows` 的计数中,如果 `filtered rows` 的数量超过了本次导入 `max_filter_ratio` 
所能容忍的上限,则整个导入将会失败。同时,被过滤的数据会在 error log 留下一条日志。
-
-2. 灵活列更新导入中每一个 json 对象中的键值对只有当它的 Key 
和目标表中某一列的列名一致时才是有效的,不满足这一要求的键值对将被忽略。同时,Key 为 
`__DORIS_VERSION_COL__`/`__DORIS_ROW_STORE_COL__`/`__DORIS_SKIP_BITMAP_COL__` 
的键值对也将被忽略。
-
-3. 当目标表的表属性中设置了 `function_column.sequence_type` 这一属性时,灵活列更新的导入可以通过在 json 对象中包括 
Key 为 `__DORIS_SEQUENCE_COL__` 的键值对来指定目标表中 `__DORIS_SEQUENCE_COL__` 列的值。对于不指定 
`__DORIS_SEQUENCE_COL__` 列的值的行,如果这一行的 Key 在原表中存在,则这一行 `__DORIS_SEQUENCE_COL__` 
列的值将被填充为旧行中对应的值,否则该列的值将被填充为 `null` 值
-
-例如,对于下表:
-```sql
-CREATE TABLE t2 (
-  `k` int(11) NULL, 
-  `v1` BIGINT NULL,
-  `v2` BIGINT NULL DEFAULT "9876",
-  `v3` BIGINT NOT NULL,
-  `v4` BIGINT NOT NULL DEFAULT "1234",
-  `v5` BIGINT NULL
-) UNIQUE KEY(`k`) DISTRIBUTED BY HASH(`k`) BUCKETS 1
-PROPERTIES(
-"replication_num" = "3",
-"enable_unique_key_merge_on_write" = "true",
-"enable_unique_key_skip_bitmap_column" = "true",
-"function_column.sequence_type" = "int");
-```
-
-表中有如下原始数据:
-```sql
-+---+----+----+----+----+----+----------------------+
-| k | v1 | v2 | v3 | v4 | v5 |__DORIS_SEQUENCE_COL__|
-+---+----+----+----+----+----+----------------------+
-| 0 | 0  | 0  | 0  | 0  | 0  | 0                    |
-| 1 | 1  | 1  | 1  | 1  | 10 | 10                   |
-| 2 | 2  | 2  | 2  | 2  | 20 | 20                   |
-| 3 | 3  | 3  | 3  | 3  | 30 | 30                   |
-| 4 | 4  | 4  | 4  | 4  | 40 | 40                   |
-| 5 | 5  | 5  | 5  | 5  | 50 | 50                   |
-+---+----+----+----+----+----+----------------------+
-```
-
-通过灵活列更新导入如下数据:
-```json
-{"k": 1, "v1": 111, "v5": 9, "__DORIS_SEQUENCE_COL__": 9}
-{"k": 2, "v2": 222, "v5": 25, "__DORIS_SEQUENCE_COL__": 25}
-{"k": 3, "v3": 333}
-{"k": 4, "v4": 444, "v5": 50, "v1": 411, "v3": 433, "v2": null, 
"__DORIS_SEQUENCE_COL__": 50}
-{"k": 5, "v5": null, "__DORIS_SEQUENCE_COL__": null}
-{"k": 6, "v1": 611, "v3": 633}
-{"k": 7, "v3": 733, "v5": 300, "__DORIS_SEQUENCE_COL__": 300}
-```
-
-最终表中的数据如下:
-```sql
-+---+--------+--------+-----+------+--------+
-| k | v1     | v2     | v3  | v4   | v5     |
-+---+--------+--------+-----+------+--------+
-| 0 | 0      | 0      | 0   | 0    | 0      |
-| 1 | 1      | 1      | 1   | 1    | 1      |
-| 5 | 5      | 5      | 5   | 5    | 5      |
-| 2 | 2      | 222    | 2   | 2    | 25     |
-| 3 | 3      | 3      | 333 | 3    | 3      |
-| 4 | 411    | <null> | 433 | 444  | 50     |
-| 6 | 611    | 9876   | 633 | 1234 | <null> |
-| 7 | <null> | 9876   | 733 | 1234 | 300    |
-+---+--------+--------+-----+------+--------+
-```
-
-4. 当目标表的表属性中设置了 `function_column.sequence_col` 这一属性时,灵活列更新导入数据的 json 对象中 Key 为 
`__DORIS_SEQUENCE_COL__` 的键值对将被忽略,导入中某一行 `__DORIS_SEQUENCE_COL__` 列的值将与这一行中表属性 
`function_column.sequence_col` 所指定的列最终的值完全一致。
-
-例如,对于下表:
-```sql
-CREATE TABLE t3 (
-  `k` int(11) NULL, 
-  `v1` BIGINT NULL,
-  `v2` BIGINT NULL DEFAULT "9876",
-  `v3` BIGINT NOT NULL,
-  `v4` BIGINT NOT NULL DEFAULT "1234",
-  `v5` BIGINT NULL DEFAULT "31"
-) UNIQUE KEY(`k`) DISTRIBUTED BY HASH(`k`) BUCKETS 1
-PROPERTIES(
-"replication_num" = "3",
-"enable_unique_key_merge_on_write" = "true",
-"enable_unique_key_skip_bitmap_column" = "true",
-"function_column.sequence_col" = "v5");
-```
-
-表中有如下原始数据:
-```sql
-+---+----+----+----+----+----+----------------------+
-| k | v1 | v2 | v3 | v4 | v5 |__DORIS_SEQUENCE_COL__|
-+---+----+----+----+----+----+----------------------+
-| 0 | 0  | 0  | 0  | 0  | 0  | 0                    |
-| 1 | 1  | 1  | 1  | 1  | 10 | 10                   |
-| 2 | 2  | 2  | 2  | 2  | 20 | 20                   |
-| 3 | 3  | 3  | 3  | 3  | 30 | 30                   |
-| 4 | 4  | 4  | 4  | 4  | 40 | 40                   |
-| 5 | 5  | 5  | 5  | 5  | 50 | 50                   |
-+---+----+----+----+----+----+----------------------+
-```
-
-通过灵活列更新导入如下数据:
-```json
-{"k": 1, "v1": 111, "v5": 9}
-{"k": 2, "v2": 222, "v5": 25}
-{"k": 3, "v3": 333}
-{"k": 4, "v4": 444, "v5": 50, "v1": 411, "v3": 433, "v2": null}
-{"k": 5, "v5": null}
-{"k": 6, "v1": 611, "v3": 633}
-{"k": 7, "v3": 733, "v5": 300}
-```
-
-最终表中的数据如下:
-```sql
-+---+--------+--------+-----+------+-----+
-| k | v1     | v2     | v3  | v4   | v5  |
-+---+--------+--------+-----+------+-----+
-| 0 | 0      | 0      | 0   | 0    | 0   |
-| 1 | 1      | 1      | 1   | 1    | 10  |
-| 5 | 5      | 5      | 5   | 5    | 50  |
-| 2 | 2      | 222    | 2   | 2    | 25  |
-| 3 | 3      | 3      | 333 | 3    | 30  |
-| 4 | 411    | <null> | 433 | 444  | 50  |
-| 6 | 611    | 9876   | 633 | 1234 | 31  |
-| 7 | <null> | 9876   | 733 | 1234 | 300 |
-+---+--------+--------+-----+------+-----+
-```
-
-5. 使用灵活列更新时不能指定或开启如下一些导入属参数:
-    - 不能指定 `merge_type` 参数
-    - 不能指定 `delete` 参数
-    - 不能开启 `fuzzy_parse` 参数
-    - 不能指定 `columns` 参数
-    - 不能指定 `jsonpaths` 参数
-    - 不能指定 `hidden_columns` 参数
-    - 不能指定 `function_column.sequence_col` 参数
-    - 不能指定 `sql` 参数
-    - 不能开启 `memtable_on_sink_node` 前移
-    - 不能指定 `group_commit` 参数
-    - 不能指定 `where` 参数
-
-6. 不支持在有 Variant 列的表上进行灵活列更新。
-
-7. 不支持在有同步物化视图的表上进行灵活列更新。
-
-
-## 部分列更新/灵活列更新中对新插入的行的处理
-
-session variable或导入属性`partial_update_new_key_behavior`用于控制部分列更新和灵活列更新中插入的新行的行为。
-
-当`partial_update_new_key_behavior=ERROR`时,插入的每一行数据必须满足该行数据的 Key 
在表中已经存在。而当`partial_update_new_key_behavior=APPEND`时,进行部分列更新或灵活列更新时可以更新 Key 
已经存在的行,也可以插入 Key 不存在的新行。
-
-例如有表结构如下:
-```sql
-CREATE TABLE user_profile
-(
-    id               INT,
-    name             VARCHAR(10),
-    age              INT,
-    city             VARCHAR(10),
-    balance          DECIMAL(9, 0),
-    last_access_time DATETIME
-) ENGINE=OLAP
-UNIQUE KEY(id)
-DISTRIBUTED BY HASH(id) BUCKETS 1
-PROPERTIES (
-    "enable_unique_key_merge_on_write" = "true"
-);
-```
-
-表中有一条数据如下:
-```sql
-mysql> select * from user_profile;
-+------+-------+------+----------+---------+---------------------+
-| id   | name  | age  | city     | balance | last_access_time   |
-+------+-------+------+----------+---------+---------------------+
-|    1 | kevin |   18 | shenzhen |     400 | 2023-07-01 12:00:00|
-+------+-------+------+----------+---------+---------------------+
-```
-
-当用户在`partial_update_new_key_behavior=ERROR`的情况下使用 Insert Into 
部分列更新向表中插入上述数据时,由于第二、三行的数据的 key(`(3)`, `(18)`) 不在原表中,所以本次插入会失败:
-```sql
-SET enable_unique_key_partial_update=true;
-SET partial_update_new_key_behavior=ERROR;
-INSERT INTO user_profile (id, balance, last_access_time) VALUES
-(1, 500, '2023-07-03 12:00:01'),
-(3, 23, '2023-07-03 12:00:02'),
-(18, 9999999, '2023-07-03 12:00:03');
-(1105, "errCode = 2, detailMessage = (127.0.0.1)[INTERNAL_ERROR]tablet error: 
[E-7003]Can't append new rows in partial update when 
partial_update_new_key_behavior is ERROR. Row with key=[3] is not in table., 
host: 127.0.0.1")
-```
-
-当用在`partial_update_new_key_behavior=APPEND`的情况下使用 Insert Into 部分列更新向表中插入如下数据时:
-```sql
-SET enable_unique_key_partial_update=true;
-SET partial_update_new_key_behavior=APPEND;
-INSERT INTO user_profile (id, balance, last_access_time) VALUES 
-(1, 500, '2023-07-03 12:00:01'),
-(3, 23, '2023-07-03 12:00:02'),
-(18, 9999999, '2023-07-03 12:00:03');
-```
-
-表中原有的一条数据将会被更新,此外还向表中插入了两条新数据。对于插入的数据中用户没有指定的列,如果该列有默认值,则会以默认值填充;否则,如果该列可以为 
NULL,则将以 NULL 值填充;否则本次插入不成功。
-
-查询结果如下:
-```sql
-mysql> select * from user_profile;
-+------+-------+------+----------+---------+---------------------+
-| id   | name  | age  | city     | balance | last_access_time    |
-+------+-------+------+----------+---------+---------------------+
-|    1 | kevin |   18 | shenzhen |     500 | 2023-07-03 12:00:01 |
-|    3 | NULL  | NULL | NULL     |      23 | 2023-07-03 12:00:02 |
-|   18 | NULL  | NULL | NULL     | 9999999 | 2023-07-03 12:00:03 |
-+------+-------+------+----------+---------+---------------------+
-```
-
+关于主键模型(Unique Key 
Model)表的列更新详细说明,包括使用示例、灵活部分列更新和新行处理等内容,请参考[列更新](./partial-column-update.md#主键模型的列更新)文档。
diff --git 
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-4.x/data-operate/update/update-overview.md
 
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-4.x/data-operate/update/update-overview.md
index 40970c3f400..139d2a0313d 100644
--- 
a/i18n/zh-CN/docusaurus-plugin-content-docs/version-4.x/data-operate/update/update-overview.md
+++ 
b/i18n/zh-CN/docusaurus-plugin-content-docs/version-4.x/data-operate/update/update-overview.md
@@ -34,7 +34,7 @@ Doris 提供了两大类数据更新方法:**通过数据导入进行更新**
 
 ![img](/images/update-overview/update-by-loading.png)
 
-1.2.2. 通过 `UPDATE` DML语句更新
+#### 1.2.2. 通过 `UPDATE` DML语句更新
 
 Doris 支持标准的 SQL `UPDATE` 语句,允许用户根据 `WHERE` 
子句指定的条件对数据进行更新。这种方式非常灵活,支持复杂的更新逻辑,例如跨表关联更新。
 
@@ -53,7 +53,7 @@ WHERE t1.user_id = t2.user_id;
 
 **注意**:`UPDATE` 语句的执行过程是先扫描满足条件的数据,然后将更新后的数据重新写回表中。它适合低频、批量的更新任务。**不建议对** 
**`UPDATE`** **语句进行高并发操作**,因为并发的 `UPDATE` 在涉及相同主键时,无法保证数据的隔离性。
 
-#### 1.2.2. 通过 `INSERT INTO SELECT` DML语句更新
+#### 1.2.3. 通过 `INSERT INTO SELECT` DML语句更新
 
 由于Doris默认提供了UPSERT的语义,因此使用`INSERT INTO SELECT`也可以实现类似于`UPDATE`的更新效果。
 
diff --git a/static/images/update-overview/update-by-loading.png 
b/static/images/update-overview/update-by-loading.png
index 383f1ee36ee..7a2ae184f1c 100644
Binary files a/static/images/update-overview/update-by-loading.png and 
b/static/images/update-overview/update-by-loading.png differ
diff --git a/static/images/update-overview/update-self.png 
b/static/images/update-overview/update-self.png
index 7a2ae184f1c..383f1ee36ee 100644
Binary files a/static/images/update-overview/update-self.png and 
b/static/images/update-overview/update-self.png differ


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to