This is an automated email from the ASF dual-hosted git repository.
kassiez 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 1d459d30bf0 [doc](mtmv) Optimize sync and async mv doc (#1671)
1d459d30bf0 is described below
commit 1d459d30bf0f5d48e56297f4368bed1ef477f641
Author: seawinde <[email protected]>
AuthorDate: Mon Dec 30 16:45:41 2024 +0800
[doc](mtmv) Optimize sync and async mv doc (#1671)
## Versions
- [x] dev
- [ ] 3.0
- [ ] 2.1
- [ ] 2.0
## Languages
- [x] Chinese
- [ ] English
## Docs Checklist
- [x] Checked by AI
- [ ] Test Cases Built
---
.../async-materialized-view/overview.md | 541 ++-------------------
.../functions-and-demands.md | 68 ++-
.../async-materialized-view/overview.md | 36 +-
.../async-materialized-view/use-guide.md | 31 +-
.../materialized-view/sync-materialized-view.md | 16 +-
5 files changed, 135 insertions(+), 557 deletions(-)
diff --git
a/docs/query-acceleration/materialized-view/async-materialized-view/overview.md
b/docs/query-acceleration/materialized-view/async-materialized-view/overview.md
index bd0066e00ca..b15b9594e67 100644
---
a/docs/query-acceleration/materialized-view/async-materialized-view/overview.md
+++
b/docs/query-acceleration/materialized-view/async-materialized-view/overview.md
@@ -25,520 +25,69 @@ under the License.
-->
-## Create Async-Materialized View
+Materialized views, as an efficient solution, combine the flexibility of views
with the high performance advantages of physical tables. They can pre-compute
and store the result sets of queries, allowing for quick retrieval of results
directly from the stored materialized view when query requests arrive, thus
avoiding the overhead of re-executing complex query statements.
-There are two ways to partition materialized views: manual partition and auto
partition based on the base table.
+## Use Cases
-### Manual Partition
+- **Query Acceleration and Concurrency Improvement**: Materialized views can
significantly enhance query speed while boosting the system's concurrent
processing capabilities, effectively reducing resource consumption.
+- **Simplifying ETL Processes**: During the Extract, Transform, Load (ETL)
process, materialized views can streamline workflows, improve development
efficiency, and make data processing smoother.
+- **Accelerating External Table Queries in Lakehouse Architecture**: In a
lakehouse architecture, materialized views can significantly enhance the query
speed for external data sources, improving data access efficiency.
+- **Improving Write Efficiency**: By reducing resource contention,
materialized views can optimize the data writing process, enhance write
efficiency, and ensure data consistency and integrity.
-When creating a materialized view without specifying partition information,
the materialized view will default to creating a single partition where all
data is stored.
+## Limitations
+- **Consistency of Asynchronous Materialized Views with Base Table Data**:
Asynchronous materialized views will eventually be consistent with the base
table data, but they cannot be synchronized in real-time, meaning real-time
consistency cannot be maintained.
+- **Support for Window Function Queries**: Currently, if a query contains
window functions, it is not supported to transparently rewrite that query to
utilize materialized views.
+- **Materialized Views with ORDER BY and Queries**: If the materialized view
itself contains an ORDER BY clause, the system does not currently support using
that materialized view for transparent query rewriting. However, please note
that the query itself can still include an ORDER BY clause.
+- **Materialized Views Joining More Tables than Query Tables**: If the number
of tables joined in the materialized view exceeds the number of tables involved
in the query (for example, if the query only involves t1 and t2, while the
materialized view includes t1, t2, and an additional t3), the system currently
does not support transparently rewriting that query to utilize the materialized
view.
-### Auto Partition Based on the Base Table
+## Principle Introduction
-Materialized views can be created through joins with multiple base tables and
can choose to follow the partitioning of one of the base tables (it is
recommended to choose the fact table).
+Materialized views, as an advanced feature in databases, essentially function
as MTMV-type internal tables. When creating a materialized view, the system
simultaneously registers a refresh task. This task will run when needed,
executing an INSERT OVERWRITE statement to write the latest data into the
materialized view.
-For example, the table creation statements for base tables `t1` and `t2` are
as follows:
+**Refresh Mechanism**
+Unlike the real-time incremental refresh used by synchronous materialized
views, asynchronous materialized views offer more flexible refresh options.
-```sql
-CREATE TABLE `t1` (
- `user_id` LARGEINT NOT NULL,
- `o_date` DATE NOT NULL,
- `num` SMALLINT NOT NULL
-) ENGINE=OLAP
-COMMENT 'OLAP'
-PARTITION BY RANGE(`o_date`)
-(
-PARTITION p20170101 VALUES [('2017-01-01'), ('2017-01-02')),
-PARTITION p20170102 VALUES [('2017-01-02'), ('2017-01-03')),
-PARTITION p20170201 VALUES [('2017-02-01'), ('2017-02-02'))
-)
-DISTRIBUTED BY HASH(`user_id`) BUCKETS 2
-PROPERTIES ('replication_num' = '1');
-
-CREATE TABLE `t2` (
- `user_id` LARGEINT NOT NULL,
- `age` SMALLINT NOT NULL
-) ENGINE=OLAP
-PARTITION BY LIST(`age`)
-(
- PARTITION `p1` VALUES IN ('1'),
- PARTITION `p2` VALUES IN ('2')
-)
-DISTRIBUTED BY HASH(`user_id`) BUCKETS 2
-PROPERTIES ('replication_num' = '1');
-```
+**Full Refresh**:
+In this mode, the system recalculates all data involved in the SQL definition
of the materialized view and writes the complete results into the materialized
view. This process ensures that the data in the materialized view remains
consistent with the base table data, but it may consume more computational
resources and time.
-If the materialized view creation statement is as follows:
+**Partition Incremental Refresh**:
+When the partition data of the base table for the materialized view changes,
the system can intelligently identify these changes and refresh only the
affected partitions. This mechanism significantly reduces the computational
resources and time required to refresh the materialized view while ensuring
eventual data consistency.
-```sql
-CREATE MATERIALIZED VIEW mv1
-BUILD DEFERRED REFRESH AUTO ON MANUAL
-partition by(`order_date`)
-DISTRIBUTED BY RANDOM BUCKETS 2
-PROPERTIES (
-'replication_num' = '1'
-)
-AS
-SELECT t1.o_date as order_date, t1.user_id as user_id, t1.num, t2.age FROM t1
join t2 on t1.user_id=t2.user_id;
-```
+**Transparent Rewriting**:
+Transparent rewriting is an important means for databases to optimize query
performance. When processing user queries, the system can automatically
optimize and rewrite the SQL to improve execution efficiency and reduce
computational costs. This rewriting process is transparent to the user,
requiring no intervention.
-Then the materialized view `mv1` will have the same three partitions as `t1`:
+Doris asynchronous materialized views utilize a transparent rewriting
algorithm based on the SPJG (SELECT-PROJECT-JOIN-GROUP-BY) model. This
algorithm can deeply analyze the structural information of SQL, automatically
searching for and selecting suitable materialized views for transparent
rewriting. When multiple materialized views are available, the algorithm will
also choose the optimal materialized view to respond to the query SQL based on
certain strategies (such as cost models), fu [...]
-- `[('2017-01-01'), ('2017-01-02'))`
+## Support for Materialized Refresh Data Lake
-- `[('2017-01-02'), ('2017-01-03'))`
+Regarding the support for materialized refresh data lakes, different types of
tables and catalogs have varying levels of support:
-- `[('2017-02-01'), ('2017-02-02'))`
+| Table Type | Catalog Type | Full Refresh | Partition Refresh | Triggered
Refresh |
+|------------|--------------|--------------|-------------------|--------------------|
+| Internal | Internal | Supported in 2.1 | Supported in 2.1 | Supported
in 2.1.4 |
+| Hive | Hive | Supported in 2.1 | Supported in 2.1 | Not
supported |
+| Iceberg | Iceberg | Supported in 2.1 | Not supported | Not
supported |
+| Paimon | Paimon | Supported in 2.1 | Not supported | Not
supported |
+| Hudi | Hudi | Supported in 2.1 | Not supported | Not
supported |
+| JDBC | JDBC | Supported in 2.1 | Not supported | Not
supported |
+| ES | ES | Supported in 2.1 | Not supported | Not
supported |
-If the materialized view creation statement is as follows:
+## Relationship Between Materialized Views and OLAP Internal Tables
-```sql
-CREATE MATERIALIZED VIEW mv2
-BUILD DEFERRED REFRESH AUTO ON MANUAL
-partition by(`age`)
-DISTRIBUTED BY RANDOM BUCKETS 2
-PROPERTIES (
-'replication_num' = '1'
-)
-AS
-SELECT t1.o_date as order_date, t1.user_id as user_id, t1.num, t2.age FROM t1
join t2 on t1.user_id=t2.user_id;
-```
-
-Then the materialized view `mv2` will have the same two partitions as `t2`:
-
-- `('1')`
-
-- `('2')`
-
-When creating materialized views that depend on base table partitions,
different partition strategies need to be designed appropriately for different
scenarios. Below are examples illustrating multi-column partitioning, partial
partitioning, and partition roll-up.
-
-**1. Base Table with Multi-Column Partitioning**
-
-:::tip
-Supported since Doris 2.1.0
+:::tips
+Starting from version 2.1.4, materialized views support the Duplicate model.
:::
-Currently, only Hive external tables support multi-column partitioning. Hive
external tables often have multi-level partitioning, for example, one level by
date and another by region. The materialized view can choose one of the
partitioning columns from Hive as its partitioning column.
-
-For example, the Hive table creation statement is as follows:
-
-```sql
-CREATE TABLE hive1 (
-`k1` int)
-PARTITIONED BY (
-`year` int,
-`region` string)
-STORED AS ORC;
-
-alter table hive1 add if not exists
-partition(year=2020,region="bj")
-partition(year=2020,region="sh")
-partition(year=2021,region="bj")
-partition(year=2021,region="sh")
-partition(year=2022,region="bj")
-partition(year=2022,region="sh")
-```
-
-
-When the materialized view creation statement is as follows, the materialized
view `mv_hive` will have three partitions: `('2020'), ('2021'), ('2022')`
-
-```sql
-CREATE MATERIALIZED VIEW mv_hive
-BUILD DEFERRED REFRESH AUTO ON MANUAL
-partition by(`year`)
-DISTRIBUTED BY RANDOM BUCKETS 2
-PROPERTIES ('replication_num' = '1')
-AS
-SELECT k1,year,region FROM hive1;
-```
-
-When the materialized view creation statement is as follows, the materialized
view `mv_hive2` will have two partitions: `('bj'), ('sh')`:
-
-```sql
-CREATE MATERIALIZED VIEW mv_hive2
-BUILD DEFERRED REFRESH AUTO ON MANUAL
-partition by(`region`)
-DISTRIBUTED BY RANDOM BUCKETS 2
-PROPERTIES ('replication_num' = '1')
-AS
-SELECT k1,year,region FROM hive1;
-```
-
-**2. Using Partial Base Table Partitioning**
-
-:::tip
-Supported since Doris 2.1.1
-:::
-
-Some base tables have many partitions, but the materialized view only focuses
on the "hot" data from a recent period. This feature can be used in such
scenarios.
-
-The base table creation statement is as follows:
-
-```sql
-CREATE TABLE t1 (
- `k1` INT,
- `k2` DATE NOT NULL
-) ENGINE=OLAP
-DUPLICATE KEY(`k1`)
-COMMENT 'OLAP'
-PARTITION BY range(`k2`)
-(
-PARTITION p26 VALUES [("2024-03-26"),("2024-03-27")),
-PARTITION p27 VALUES [("2024-03-27"),("2024-03-28")),
-PARTITION p28 VALUES [("2024-03-28"),("2024-03-29"))
-)
-DISTRIBUTED BY HASH(`k1`) BUCKETS 2
-PROPERTIES (
-'replication_num' = '1'
-);
-```
-
-The materialized view creation statement, representing that the materialized
view only focuses on the data from the last day, is as follows. If the current
time is 2024-03-28 xx:xx:xx, the materialized view will only have one partition
`[("2024-03-28"),("2024-03-29")]`:
-
-```sql
-CREATE MATERIALIZED VIEW mv1
-BUILD DEFERRED REFRESH AUTO ON MANUAL
-partition by(`k2`)
-DISTRIBUTED BY RANDOM BUCKETS 2
-PROPERTIES (
-'replication_num' = '1',
-'partition_sync_limit'='1',
-'partition_sync_time_unit'='DAY'
-)
-AS
-SELECT * FROM t1;
-```
-
-If the time passes by another day, and the current time becomes `2024-03-29
xx:xx:xx`, `t1` will add a new partition `[("2024-03-29"),("2024-03-30")]`. If
the materialized view is refreshed at this point, after the refresh, the
materialized view will only have one partition
`[("2024-03-29"),("2024-03-30")]`.
-
-Additionally, if the partition field is of string type, you can set the
materialized view property `partition_date_format`, such as `%Y-%m-%d`.
-
-**3. Partition Roll-Up**
-
-:::tip
-Supported since Doris 2.1.5
-:::
-
-When the base table data is aggregated, the data volume in each partition may
significantly decrease. In such cases, a partition roll-up strategy can be
adopted to reduce the number of partitions in the materialized view.
-
-- List Partitioning
-
- Note that partitions in Hive correspond to the list partitions in Doris.
-
- Assuming the base table creation statement is as follows:
-
- ```sql
- CREATE TABLE `t1` (
- `k1` INT NOT NULL,
- `k2` DATE NOT NULL
- ) ENGINE=OLAP
- DUPLICATE KEY(`k1`)
- COMMENT 'OLAP'
- PARTITION BY list(`k2`)
- (
- PARTITION p_20200101 VALUES IN ("2020-01-01"),
- PARTITION p_20200102 VALUES IN ("2020-01-02"),
- PARTITION p_20200201 VALUES IN ("2020-02-01")
- )
- DISTRIBUTED BY HASH(`k1`) BUCKETS 2
- PROPERTIES ('replication_num' = '1');
- ```
-
- If the materialized view creation statement is as follows, the
materialized view will have two partitions: `("2020-01-01","2020-01-02")` and
`("2020-02-01")`
-
- ```sql
- CREATE MATERIALIZED VIEW mv1
- BUILD DEFERRED REFRESH AUTO ON MANUAL
- partition by (date_trunc(`k2`,'month'))
- DISTRIBUTED BY RANDOM BUCKETS 2
- PROPERTIES (
- 'replication_num' = '1'
- )
- AS
- SELECT * FROM t1;
- ```
-
- If the materialized view creation statement is as follows, the
materialized view will have only one partition:
`("2020-01-01","2020-01-02","2020-02-01")`
-
- ```sql
- CREATE MATERIALIZED VIEW mv1
- BUILD DEFERRED REFRESH AUTO ON MANUAL
- partition by (date_trunc(`k2`,'year'))
- DISTRIBUTED BY RANDOM BUCKETS 2
- PROPERTIES (
- 'replication_num' = '1'
- )
- AS
- SELECT * FROM t1;
- ```
-
-- Range Partitioning
-
- Assuming the base table creation statement is as follows:
-
- ```sql
- CREATE TABLE `t1` (
- `k1` LARGEINT NOT NULL,
- `k2` DATE NOT NULL
- ) ENGINE=OLAP
- DUPLICATE KEY(`k1`)
- COMMENT 'OLAP'
- PARTITION BY range(`k2`)
- (
- PARTITION p_20200101 VALUES [("2020-01-01"),("2020-01-02")),
- PARTITION p_20200102 VALUES [("2020-01-02"),("2020-01-03")),
- PARTITION p_20200201 VALUES [("2020-02-01"),("2020-02-02"))
- )
- DISTRIBUTED BY HASH(`k1`) BUCKETS 2
- PROPERTIES ('replication_num' = '1');
- ```
-
- If the materialized view creation statement is as follows, the
materialized view will have two partitions: `[("2020-01-01","2020-02-01")]` and
`[("2020-02-01","2020-03-01")]`
-
- ```sql
- CREATE MATERIALIZED VIEW mv1
- BUILD DEFERRED REFRESH AUTO ON MANUAL
- partition by (date_trunc(`k2`,'month'))
- DISTRIBUTED BY RANDOM BUCKETS 2
- PROPERTIES (
- 'replication_num' = '1'
- )
- AS
- SELECT * FROM t1;
- ```
-
- If the materialized view creation statement is as follows, the
materialized view will have only one partition: `[("2020-01-01","2021-01-01")]`
-
- ```sql
- CREATE MATERIALIZED VIEW mv1
- BUILD DEFERRED REFRESH AUTO ON MANUAL
- partition by (date_trunc(`k2`,'year'))
- DISTRIBUTED BY RANDOM BUCKETS 2
- PROPERTIES (
- 'replication_num' = '1'
- )
- AS
- SELECT * FROM t1;
- ```
-
- Additionally, if the partition field is of string type, you can specify
the date format by setting the `partition_date_format` property of the
materialized view, such as `'%Y-%m-%d'`.
-
-## Refresh Async-Materialized View
-
-Materialized views are refreshed on a per-partition basis. If no specific
partition is designated for the materialized view, its default partition will
be refreshed during each refresh operation, effectively refreshing all data
within the materialized view.
-
-There are three trigger mechanisms for refreshing materialized views:
-
-### Manual Refresh
-
-Users can trigger the refresh of materialized views through SQL statements.
Currently, there are three strategies:
-
-- Refresh without concern for specific partitions, requiring that the data in
the materialized view synchronizes with the base table upon completion.
-
- ```sql
- REFRESH MATERIALIZED VIEW mvName AUTO;
- ```
-
-- Refresh all partitions of the materialized view, regardless of its current
data.
-
- ```sql
- REFRESH MATERIALIZED VIEW mvName COMPLETE;
- ```
-
-- Refresh only specified partitions of the materialized view, regardless of
its current data.
-
- ```sql
- REFRESH MATERIALIZED VIEW mvName partitions(partitionName1,partitionName2);
- ```
-
-::: tip
-`partitionName` can be retrieved through `SHOW PARTITIONS FROM mvName`.
-:::
-
-### Scheduled Refresh
-
-The interval for refreshing data can be specified through the materialized
view creation statement.
-
-- If the materialized view creation statement is as follows, requiring a full
refresh (`REFRESH COMPLETE`), the materialized view will refresh every 10
hours, refreshing all partitions.
-
- ```sql
- CREATE MATERIALIZED VIEW mv1
- REFRESH COMPLETE ON SCHEDULE EVERY 10 HOUR
- PARTITION BY(`xxx`)
- AS
- SELECT ...;
- ```
-
-- If the materialized view creation statement is as follows, requiring
automatic calculation of partitions to refresh (`REFRESH AUTO`), the
materialized view will refresh every 10 hours (since version 2.1.3, it can
automatically calculate partitions to refresh for Hive).
-
- ```sql
- CREATE MATERIALIZED VIEW mv1
- REFRESH AUTO ON SCHEDULE EVERY 10 HOUR
- PARTITION BY(`xxx`)
- AS
- SELECT ...;
- ```
-
-### Auto Refresh
-
-:::tip
-Supported since Apache Doris version 2.1.4.
-:::
-
-After data in the base table changes, the related materialized views are
automatically triggered for refresh, with the same partition scope as scheduled
triggers.
-
-If the materialized view creation statement is as follows, when data in `t1`
changes, it will automatically trigger the refresh of the materialized view.
-
-```sql
-CREATE MATERIALIZED VIEW mv1
-REFRESH ON COMMIT
-PARTITION BY(`xxx`)
-AS
-SELECT ... FROM t1;
-```
-
-## Transparent Rewrite
-
-Doris's async-materialized views employ an algorithm based on SPJG
(SELECT-PROJECT-JOIN-GROUP-BY) pattern structural information for transparent
rewrite. Doris can analyze the structural information of query SQL,
automatically search for materialized views that meet the requirements, and
attempt transparent rewrite, using the optimal materialized view to express the
query SQL.
-
-### Flow Chart
-
-
-
-### Transparent Rewrite Based on Structural Information
-
-As shown in the flowchart, after obtaining the query structure corresponding
to the materialization, transparent rewrite will be based on structural
information. At this point, the following verifications are required:
-
-**1. Verify if the materialized view contains all rows required for the query**
-
-- For the query: `SELECT * FROM T1, T2, …, Tm WHERE Wq`
-
-- For the materialized view: `SELECT * FROM T1, T2, …, Tm WHERE Wv`
-
-:::caution
-The query conditions must be stronger than or equal to the materialized
conditions.
-:::
-
-Where T1, T2 are tables, Wq represents the WHERE filter condition of the
query, and Wv represents the WHERE filter condition of the materialized view.
To ensure that the view contains all rows required by the query, the filter
condition Wq must be able to derive Wv, i.e., `Wq -> Wv` (for example, if `Wq >
20` and `Wv > 10`, Wq can derive Wv).
-
-The expression W can be further refined, with filter expressions divisible
into three parts: PE ∧ PR ∧ PU.
-
-- PE represents equal expressions;
-
-- PR represents range filter expressions, using operators such as "<", "≤",
"=", "≥", ">";
-
-- PU represents residual expressions excluding the aforementioned.
-
-Therefore, based on `Wq -> Wv`, we can derive `(PEq ∧ PRq ∧ PUq → PEv ∧ PRv ∧
PUv)`. Where q represents the query, and v represents the materialized view.
-
-Since A -> C, then AB -> C. The above expression can be further derived as
follows:
-
-```Plain
-(PEq∧ PRq∧PUq⇒ PEv )∧
-(PEq∧ PRq∧PUq⇒ PRv)∧
-(PEq∧ PRq∧PUq⇒ PUv)
-```
-
-Which can be further simplified to:
-
-```Plain
-(PEq ⇒ PEv ) (Equijoin subsumption test - Equivalence condition verification)
-(PEq ∧ PRq ⇒ PRv) (Range subsumption test - Range condition verification)
-(PEq ∧ PUq ⇒ PUv ) (Residual subsumption test - Residual condition
verification)
-```
-
-- Equivalence condition verification: The general principle is that the equal
expressions of the materialized view are a subset of the query's equal
expressions. Equivalent expressions are transitive and should maintain
correctness.
-
-- The range expressions of the view should encompass those of the query. For
example, T=constant can be converted to T>=constant AND T<=constant.
-
-- Using Expression Equals, verify if the residual expressions appearing in the
materialized view are a subset of those in the query.
-
-Next, we will further explain the verification steps through examples:
-
-Materialized view definition:
-
-```sql
-SELECT l_orderkey, o_custkey, l_partkey,
-l_shipdate, o_orderdate,
-l_quantity*l_extendedprice AS gross_revenue
-FROM dbo.lineitem, dbo.orders, dbo.part
-WHERE l_orderkey = o_orderkey
-AND l_partkey = p_partkey
-AND p_partkey >= 150
-AND o_custkey >= 50 AND o_custkey <= 500
-AND p_name LIKE '%abc%'
-```
-
-Query definition:
-
-```sql
-SELECT l_orderkey, o_custkey, l_partkey,
-l_quantity*l_extendedprice
-FROM lineitem, orders, part
-WHERE l_orderkey = o_orderkey
-AND l_partkey = p_partkey
-AND l_partkey >= 150 AND l_partkey <= 160
-AND o_custkey = 123
-AND o_orderdate = l_shipdate
-AND p_name LIKE '%abc%'
-AND l_quantity*l_extendedprice > 100
-```
-
-Step 1: Calculate equivalence classes
-
-- View equivalence classes: `{l_orderkey, o_orderkey},{l_partkey, p_partkey},
{o_orderdate}, {l_shipdate}`
-
-- Query equivalence classes: `{l_orderkey, o_orderkey},{l_partkey, p_partkey},
{o_orderdate, l_shipdate}`
-
-Step 2: verify equivalence equivalence classes
-
-- If the view equivalence expression is a subset of the query equivalence
expression, the verification passes.
-
-Step 3: Calculate range expressions
-
-- View range expressions: `{l_partkey, p_partkey} ∈ (150, +∞), {o_custkey} ∈
(50, 500)`
-
-- Query range expressions: `{l_partkey, p_partkey} ∈ (150, 160), {o_custkey} ∈
(123, 123)`
-
-Step 4: Verify range expressions
-
-- View range expressions: (150, 160) falls within (150, +∞)
-
-- Query range expressions: (123, 123) falls within (50, 500)
-
-Step 5: Verify residual expressions
-
-- View residual expression: p_name LIKE '%abc%'
-
-- Query residual expression: p_name LIKE '%abc%'
-
-Since `l_quantity*l_extendedprice > 100`, the view's residual expression is a
subset of the query's. After verifying the above steps, we can ensure all rows
are retrieved from the view, and compensation conditions need to be added to
the view:
-
-```sql
-(o_orderdate = l_shipdate),
-({p_partkey,l_partkey} <= 160),
-(o_custkey = 123), and
-(l_quantity*l_extendedprice > 100.00).
-```
-
-**2. Verify if the compensation conditions can be obtained from the
materialized view**
-
-To ensure the final data obtained is consistent with the original query,
compensation conditions need to be added to the view. Verification is required
to confirm if the columns or expressions selected in the compensation
conditions can be obtained from the view.
-
-This involves verifying if columns `o_orderdate`, `l_shipdate`, `p_partkey`,
`{p_partkey, l_partkey}`, `o_custkey`, and expression
`l_quantity*l_extendedprice` can be obtained from the view.
-
-**3. Verify if expressions and columns can be obtained from the materialized
view**
-
-Similar to verifying compensation conditions, if the output expression is a
constant, it can be directly copied from the view. If it's a simple column
reference, verify if it can be obtained from the view. For expressions, if the
columns in the expression can be obtained from the materialized view, obtain
them directly; otherwise, the verification fails.
-
-**4. Verify consistency in output data duplication**
-
-For data obtained through queries and materialized views, the number of
duplicate rows must be the same. If the tables referenced by the query and
materialized view are the same, this issue will not arise. Duplicates and their
counts may differ only when the tables referenced by the query and materialized
view are different, especially in star schema queries with an additional join
that is not a primary-foreign key relationship, potentially leading to data
expansion and inconsistent dupl [...]
+The underlying implementation of materialized views relies on OLAP tables of
the Duplicate model, which theoretically allows them to support all core
functionalities of the Duplicate model. However, to ensure that materialized
views can execute data refresh tasks stably and efficiently, we have imposed a
series of necessary restrictions on their functionality. The specific
restrictions are as follows:
-Usually, it's necessary to verify the JOIN types of the materialized view and
query for the same tables and whether JOIN elimination is satisfied for
different tables.
+- The partitions of materialized views are automatically created and
maintained based on their base tables, so users cannot perform partition
operations on materialized views.
+- Since there are related jobs (JOB) that need to be processed behind
materialized views, commands like DELETE TABLE or RENAME TABLE cannot be used
to operate on materialized views. Instead, the commands specific to the
materialized view must be used for these operations.
+- The column data types of materialized views are automatically inferred based
on the query statement specified at creation, so these data types cannot be
modified. Otherwise, it may lead to failures in the refresh tasks of the
materialized view.
+- Materialized views have some properties that Duplicate tables do not
possess, and these properties need to be modified through the commands of the
materialized view. Other common properties should be modified using the ALTER
TABLE command.
-**5. Aggregation verification**
+## More References
+For creating, querying, and maintaining asynchronous materialized views, you
can refer to [Creating, Querying, and Maintaining Asynchronous Materialized
Views](../functions-and-demands).
-- Verify if the materialized dimensions are finer than those of the query and
if they encompass the query's dimensions.
+For best practices, you can refer to [Best Practices](../use-guide).
-- Verify if the aggregation functions used in the query can be obtained from
the materialized view or derived through roll-up of the materialized view's
functions.
\ No newline at end of file
+For frequently asked questions, you can refer to [Frequently Asked
Questions](../faq).
\ No newline at end of file
diff --git
a/i18n/zh-CN/docusaurus-plugin-content-docs/current/query-acceleration/materialized-view/async-materialized-view/functions-and-demands.md
b/i18n/zh-CN/docusaurus-plugin-content-docs/current/query-acceleration/materialized-view/async-materialized-view/functions-and-demands.md
index 3b854eac249..f533ba0ca0d 100644
---
a/i18n/zh-CN/docusaurus-plugin-content-docs/current/query-acceleration/materialized-view/async-materialized-view/functions-and-demands.md
+++
b/i18n/zh-CN/docusaurus-plugin-content-docs/current/query-acceleration/materialized-view/async-materialized-view/functions-and-demands.md
@@ -106,9 +106,20 @@ INSERT INTO partsupp VALUES
(2, 3, 10, 11.01, 'supply3');
```
+#### 刷新基础概念
+
+| 概念 | 说明 |
+|----------|-----------------------------------------------------------------|
+| 刷新时机 | 物化视图创建完成是否立即刷新。IMMEDIATE：立即刷新，默认IMMEDIATE。DEFERRED：延迟刷新 |
+| 刷新方式 | COMPLETE：刷新所有分区。AUTO：尽量增量刷新，只刷新自上次物化刷新后数据变化的分区，如果不能增量刷新，就刷新所有分区 |
+| 触发方式 | MANUAL：手动刷新。ON SCHEDULE：定时刷新。ON COMMIT：触发式刷新，基表数据变更，触发物化视图刷新 |
+
+
#### 全量物化视图
-触发方式是手动，刷新方式是 AUTO，如下
+如下，刷新时机是创建完立即刷新，刷新方式是 AUTO，即尽量增量刷新，只刷新自上次物化刷新后数据变化的分区，如果不能增量刷新，就刷新所有分区。
+触发方式是手动。
+对于非分区全量物化视图，只有一个分区，如果基表数据发生变化，意味着要全量刷新。
```sql
CREATE MATERIALIZED VIEW mv_1_0
@@ -124,9 +135,9 @@ FROM
LEFT JOIN lineitem ON l_orderkey = o_orderkey;
```
-延迟刷新，首次刷新时间是 `2024-12-01 20:30:00`, 并且每隔一天刷新一次。如果 `BUILD DEFERRED` 指定为 `BUILD
IMMEDIATE` 创建
-完物化视图会立即刷新一次。之后从 `2024-12-01 20:30:00` 每隔一天刷新一次
-注意 STARTS 的时间要晚于当前的时间。如下
+如下，刷新时机是延迟刷新，刷新方式是全量刷新，触发时机是定时刷新，首次刷新时间是 `2024-12-01 20:30:00`, 并且每隔一天刷新一次。如果
`BUILD DEFERRED` 指定为 `BUILD IMMEDIATE` 创建
+完物化视图会立即刷新一次。之后从 `2024-12-01 20:30:00` 每隔一天刷新一次。
+注意 STARTS 的时间要晚于当前的时间。
```sql
CREATE MATERIALIZED VIEW mv_1_1
@@ -144,7 +155,7 @@ orders
LEFT JOIN lineitem ON l_orderkey = o_orderkey;
```
-刷新方式是触发式，当 orders 或者 lineitem 表数据发生变化的时候，会自动触发物化视图的刷新。如下
+如下，刷新时机是创建完立即刷新，刷新方式是全量刷新，触发方式是触发刷新，当 orders 或者 lineitem
表数据发生变化的时候，会自动触发物化视图的刷新。
```sql
CREATE MATERIALIZED VIEW mv_1_1
@@ -166,8 +177,9 @@ LEFT JOIN lineitem ON l_orderkey = o_orderkey;
#### 分区物化视图
-创建分区物化视图时，需要指定 `partition by`，对于分区字段引用的表达式，仅允许使用 `date_trunc`
函数和标识符。以下语句是符合要求的：
-分区字段引用的列仅使用了 `date_trunc` 函数。
+如下，创建分区物化视图时，需要指定 `partition by`，对于分区字段引用的表达式，仅允许使用 `date_trunc`
函数和标识符。以下语句是符合要求的：
+分区字段引用的列仅使用了 `date_trunc` 函数。分区物化视图的刷新方式一般是 AUTO，即尽量增量刷新，只刷新自上次物化刷新后数据变化的分区，
+如果不能增量刷新，就刷新所有分区。
```sql
CREATE MATERIALIZED VIEW mv_2_0 BUILD IMMEDIATE REFRESH AUTO ON MANUAL
@@ -255,7 +267,7 @@ SELECT k1,year,region FROM hive1;
自 Doris 2.1.1 版本起支持此功能
:::
-有些基表有很多分区，但是物化视图只关注最近一段时间的“热”数据，那么可以使用此功能。
+有些基表有很多分区，但是物化视图只关注最近一段时间的"热"数据，那么可以使用此功能。
基表的建表语句如下：
@@ -275,7 +287,7 @@ PARTITION p28 VALUES [("2024-03-28"),("2024-03-29"))
DISTRIBUTED BY HASH(`k1`) BUCKETS 2;
```
-物化视图的创建语句如以下举例，代表物化视图只关注最近一天的数据。若当前时间为 2024-03-28 xx:xx:xx，这样物化视图会仅有一个分区
`[("2024-03-28"),("2024-03-29")]`：
+物化视图的创建语句如以下，代表物化视图只关注最近一天的数据。若当前时间为 2024-03-28 xx:xx:xx，这样物化视图会仅有一个分区
`[("2024-03-28"),("2024-03-29")]`：
```sql
CREATE MATERIALIZED VIEW mv1
@@ -346,7 +358,7 @@ SELECT * FROM t1;
此外，如果分区字段为字符串类型，可以通过设置物化视图的 `partition_date_format` 属性来指定日期格式，例如 `'%Y-%m-%d'`。
-**详情参考** **[CREATE ASYNC MATERIALIZED
VIEW](../../../sql-manual/sql-statements/Data-Definition-Statements/Create/CREATE-ASYNC-MATERIALIZED-VIEW)**
+详情参考 [CREATE ASYNC MATERIALIZED
VIEW](../../../sql-manual/sql-statements/Data-Definition-Statements/Create/CREATE-ASYNC-MATERIALIZED-VIEW)
### 物化视图修改
```sql
@@ -377,10 +389,10 @@ SHOW CREATE MATERIALIZED VIEW mv_1;
物化视图可以看作是表，可以像正常的表一样直接查询。
-**物化视图的定义：**
-
### 直查物化视图
+**物化视图的定义：**
+
```sql
CREATE MATERIALIZED VIEW mv_5
BUILD IMMEDIATE REFRESH AUTO ON SCHEDULE EVERY 1 hour
@@ -800,7 +812,7 @@ where o_orderstatus = 'o'
1. 嵌套物化视图的层数越多，透明改写的耗时会相应增加。建议嵌套物化视图层数不要超过 3 层。
-2. 嵌套物化视图透明改写默认关闭，开启方式见下面的开关设置。
+2. 嵌套物化视图透明改写默认关闭，开启方式见下面的相关设置。
### Explain 查询透明改写情况
@@ -846,14 +858,26 @@ explain memo plan <query_sql>
### 权限说明
-- 暂停/恢复/取消/刷新物化视图：需要具有物化视图的创建权限 。
+- 暂停/恢复/取消/刷新物化视图：需要具有物化视图的创建权限。
### 刷新物化视图
-物化视图是按照分区为单位进行刷新的。如果物化视图没有指定分区，那么每次都刷新物化视图的默认分区，即刷新物化视图的全部数据。
-物化视图有三种触发刷新机制：
+#### 刷新时机
+物化视图创建完成是否立即刷新
+- IMMEDIATE：立即刷新，默认方式。
+- DEFERRED：延迟刷新。
+
+#### 刷新方式
+- COMPLETE：刷新所有分区。
+- AUTO：尽量增量刷新，只刷新自上次物化刷新后数据变化的分区，如果不能增量刷新，就刷新所有分区。
+
+#### 触发方式
+物化视图是按照分区为单位进行刷新的。如果物化视图没有指定分区，那么每次都刷新物化视图的所有分区，对于非分区物化视图，
+只有一个分区，即刷新所有数据。
+
+物化视图有三种触发方式：
-#### 1. 手动触发
+**1. 手动触发**
用户通过 SQL 语句触发物化视图的刷新，目前有三种策略：
@@ -880,11 +904,11 @@ explain memo plan <query_sql>
从 2.1.3 版本开始支持 Hive 检测基表的分区数据自上次刷新后是否有变化，其他外表暂时还不支持。内表一直支持。
:::
-#### 2. 定时触发
+**2. 定时触发**
通过物化视图的创建语句指定间隔多久刷新一次数据
-- 如果物化视图的创建语句如下，要求全量刷新 (`REFRESH COMPLETE`)，那么物化视图每 10 小时刷新一次，并且刷新物化视图的所有分区。
+- 如下，要求全量刷新 (`REFRESH COMPLETE`)，物化视图每 10 小时刷新一次，并且刷新物化视图的所有分区。
```sql
CREATE MATERIALIZED VIEW mv_6
@@ -893,7 +917,7 @@ explain memo plan <query_sql>
SELECT * FROM lineitem;
```
-- 如果物化视图的创建语句如下，要求自动计算需要刷新的分区 (`REFRESH AUTO`)，那么物化视图每 10 小时刷新一次（从 2.1.3
版本开始能自动计算 Hive 需要刷新的分区）。
+- 如下，尽量增量刷新(`REFRESH AUTO`)，只刷新自上次物化刷新后数据变化的分区，如果不能增量刷新，就刷新所有分区，物化视图每 10
小时刷新一次（从 2.1.3 版本开始能自动计算 Hive 需要刷新的分区）。
```sql
CREATE MATERIALIZED VIEW mv_7
@@ -903,7 +927,7 @@ explain memo plan <query_sql>
SELECT * FROM lineitem;
```
-#### 3. 自动触发
+**3. 自动触发**
:::tip 提示
自 Apache Doris 2.1.4 版本起支持此功能。
@@ -911,7 +935,7 @@ explain memo plan <query_sql>
基表数据发生变更后，自动触发相关物化视图刷新，刷新的分区范围与“定时触发”一致。
-如果物化视图的创建语句如下，那么当 `t1` 的数据发生变化时，会自动触发物化视图的刷新。
+如果物化视图的创建语句如下，那么当 基表 `lineitem` 的 `t1` 分区数据发生变化时，会自动触发物化视图的对应分区刷新。
```sql
CREATE MATERIALIZED VIEW mv_8
diff --git
a/i18n/zh-CN/docusaurus-plugin-content-docs/current/query-acceleration/materialized-view/async-materialized-view/overview.md
b/i18n/zh-CN/docusaurus-plugin-content-docs/current/query-acceleration/materialized-view/async-materialized-view/overview.md
index 71853418b87..ce1525c2300 100644
---
a/i18n/zh-CN/docusaurus-plugin-content-docs/current/query-acceleration/materialized-view/async-materialized-view/overview.md
+++
b/i18n/zh-CN/docusaurus-plugin-content-docs/current/query-acceleration/materialized-view/async-materialized-view/overview.md
@@ -48,11 +48,11 @@ under the License.
**刷新机制**
与同步物化视图所采用的实时增量刷新不同，异步物化视图提供了更为灵活的刷新选项
-**全量刷新：**
+- **全量刷新：**
在此模式下，系统会重新计算物化视图定义SQL所涉及的所有数据，并将结果完整地写入物化视图。
此过程确保了物化视图中的数据与基表数据保持一致，但可能会消耗更多的计算资源和时间。
-**分区增量刷新：**
+- **分区增量刷新：**
当物化视图的基表分区数据发生变化时，系统能够智能地识别出这些变化，并仅针对受影响的分区进行刷新。
这种机制显著降低了刷新物化视图所需的计算资源和时间，同时保证了数据的最终一致性。
@@ -67,25 +67,23 @@ Doris异步物化视图采用了基于SPJG（SELECT-PROJECT-JOIN-GROUP-BY）模
## 物化刷新数据湖支持情况
-对于物化刷新数据湖的支持情况，不同类型的表和 Catalog 有不同的支持程度：
+物化刷新数据湖的支持情况，不同类型的表和 Catalog 有不同的支持程度：
-| 表类型 | Catalog 类型 | 全量刷新 | 分区刷新 | 触发刷新 |
-| ------- |----------------|--------| -------- |----------|
-| 内表 | Internal | 2.1 支持 | 2.1 支持 | 2.1.4 支持 |
-| Hive | Hive | 2.1 支持 | 2.1 支持 | 不支持 |
-| Iceberg | Iceberg | 2.1 支持 | 不支持 | 不支持 |
-| Paimon | Paimon | 2.1 支持 | 不支持 | 不支持 |
-| Hudi | Hudi | 2.1 支持 | 不支持 | 不支持 |
-| JDBC | JDBC | 2.1 支持 | 不支持 | 不支持 |
-| ES | ES | 2.1 支持 | 不支持 | 不支持 |
+| 表类型 | Catalog 类型 | 刷新方式-全量刷新 | 刷新方式-分区刷新 | 刷新时机-触发刷新 |
+| ------- |----------------|---------------|-----------|-----------|
+| 内表 | Internal | 2.1 支持 | 2.1 支持 | 2.1.4 支持 |
+| Hive | Hive | 2.1 支持 | 2.1 支持 | 不支持 |
+| Iceberg | Iceberg | 2.1 支持 | 不支持 | 不支持 |
+| Paimon | Paimon | 2.1 支持 | 不支持 | 不支持 |
+| Hudi | Hudi | 2.1 支持 | 不支持 | 不支持 |
+| JDBC | JDBC | 2.1 支持 | 不支持 | 不支持 |
+| ES | ES | 2.1 支持 | 不支持 | 不支持 |
## 物化视图和 OLAP 内表关系
-:::tips
-自 2.1.4 版本起，物化视图支持 Duplicate 模型
-:::
+异步物化视图定义 SQL 使用基表的表模型没有限制，可以是明细模型，主键模型（merge-on-write 和 merge-on-read），聚合模型等。
-物化视图的底层实现依托于Duplicate模型的OLAP表，这一设计使其理论上能够支持Duplicate模型的所有核心功能。然而，
+物化视图自身的底层实现依托于Duplicate模型的OLAP表，这一设计使其理论上能够支持Duplicate模型的所有核心功能。然而，
为了保障物化视图能够稳定且高效地执行数据刷新任务，我们对其功能进行了一系列必要的限制。以下是具体的限制内容：
- 物化视图的分区是基于其基表自动创建和维护的，因此用户不能对物化视图进行分区操作
@@ -97,9 +95,9 @@ Doris异步物化视图采用了基于SPJG（SELECT-PROJECT-JOIN-GROUP-BY）模
## 更多参考
-创建、查询与维护异步物化视图，可以参考 [创建、查询与维护异步物化视图](../functions-and-demands)
+创建、查询与维护异步物化视图，可以参考
[创建、查询与维护异步物化视图](../async-materialized-view/functions-and-demands.md)
-最佳实践，可以参考 [最佳实践](../use-guide)
+最佳实践，可以参考 [最佳实践](../async-materialized-view/use-guide.md)
-常见问题，可以参考 [常见问题](../faq)
+常见问题，可以参考 [常见问题](../async-materialized-view/faq.md)
diff --git
a/i18n/zh-CN/docusaurus-plugin-content-docs/current/query-acceleration/materialized-view/async-materialized-view/use-guide.md
b/i18n/zh-CN/docusaurus-plugin-content-docs/current/query-acceleration/materialized-view/async-materialized-view/use-guide.md
index 2603915594a..465050f1dde 100644
---
a/i18n/zh-CN/docusaurus-plugin-content-docs/current/query-acceleration/materialized-view/async-materialized-view/use-guide.md
+++
b/i18n/zh-CN/docusaurus-plugin-content-docs/current/query-acceleration/materialized-view/async-materialized-view/use-guide.md
@@ -73,7 +73,8 @@ under the License.
-
如果物化视图引用的非分区表发生数据变更，会触发物化视图所有分区失效，导致此物化视图不能用于透明改写。需要刷新物化视图所有分区的数据，命令为`REFRESH
MATERIALIZED VIEW mv1 AUTO;`。此命令会尝试刷新物化视图所有数据变化的分区。
因此，一般将数据频繁变化的表放在分区物化视图引用的分区表，将不经常变化的维表放在非引用分区表的位置。
-
+- 如果物化视图引用的非分区表发生数据变更，非分区表数据只是新增，不涉及修改，创建物化视图的时候可以指定属性
+`excluded_trigger_tables =
'非分区表名1,非分区表名2'`，这样非分区表的数据变化就不会使物化视图的所有分区失效，下次刷新时，只刷新分区表对应的物化视图失效分区。
分区物化视图的透明改写是分区粒度的，即使物化视图的部分分区失效，此物化视图仍然可用于透明改写。但如果只查询了一个分区，并且物化视图这个分区数据失效了，那么此物化视图不能用于透明改写。
@@ -298,6 +299,10 @@ GROUP BY
### 场景一：查询加速
+在 BI 报表场景或其他加速场景中，用户对于查询响应时间较为敏感，通常要求能够秒级别返回结果。而查询通常涉及多张表先进行 Join 计算、再聚合计算，
+该过程会消耗大量计算资源，并且有时难以保证时效性。对此，异步物化视图能够很好应对，它不仅支持直接查询，也支持透明改写，
+优化器会依据改写算法和代价模型，自动选择最优的物化视图来响应请求。
+
#### 用例1 多表连接聚合查询加速
通过构建更通用的物化视图能够加速多表连接聚合查询。
@@ -487,16 +492,17 @@ SELECT
### 场景二：数据建模（ETL）
-有时用户会使用事实表和维度表加工成一张汇总表，之后对此汇总表进行 Ad-hoc 查询。此汇总表也可作为基础指标表，用于后续的建模。
-
-此时，可以利用物化视图对基表的数据进行建模。之后，还可以利用创建好的物化视图创建更高层级的物化视图（2.1.3 支持），灵活满足不同的需求。
+数据分析工作往往需要对多表进行连接和聚合，这一过程通常涉及复杂且频繁重复的查询。
+这类查询可能引发查询延迟高或资源消耗大的问题。然而，如果采用异步物化视图构建数据分层模型，则可以很好避免该问题，
+利用创建好的物化视图创建更高层级的物化视图（2.1.3 支持），灵活满足不同的需求。
-不同层级的物化视图都可以自己设置刷新方式，例如：
+不同层级的物化视图可以设置各自的触发方式，例如：
- 第一层的物化视图可以设置为定时刷新，第二层的设置为触发刷新。这样，第一层的物化视图刷新完成后，会自动触发第二层物化视图的刷新。
-
-
如果每层的物化视图都设置为定时刷新，那么第二层物化视图刷新的时候，不会考虑第一层的物化视图数据是否和基表同步，只会把第一层物化视图的数据加工后同步到第二层。
+接下来，通过 TPC-H 数据集说明异步物化视图在数据建模中的应用，以分析每月各地区和国家的订单数量和利润为例：
+
原始查询（未使用物化视图）：
```sql
SELECT
@@ -577,12 +583,13 @@ GROUP BY nation_name, month;
### 场景三：湖仓一体联邦数据查询
-很多用户有基于 Doris 进行联邦数据查询的需求，Doris 的多源数据目录（Multi-Catalog）功能使得这一需求变得十分便捷。用户只需创建一个
Catalog，无需将数据迁移到 Doris，即可通过 Doris 对外部数据进行查询。
-
-然而，这种方式也可能带来一些问题。因为查询外部数据的速度可能会受到网络及第三方服务的影响，导致响应速度较慢，对于响应速度要求比较高的场景，可能难以满足需求。
-
-为了解决这个问题，可以基于外部 Catalog 创建异步物化视图。由于物化视图本身的数据是存储在 Doris
内部的，所以查询物化视图的速度会很快。因此，对于响应速度要求比较高的场景，我们可以考虑基于外部 Catalog 创建一个物化视图。
-
+在现代化的数据架构中，企业通常会采用湖仓一体设计，以平衡数据的存储成本与查询性能。在这种架构下，经常会遇到两个关键挑战：
+- 查询性能受限：频繁查询数据湖中的数据时，可能会受到网络延迟和第三方服务的影响，从而导致查询延迟，进而影响用户体验。
+- 数据分层建模的复杂性：在数据湖到实时数仓的数据流转和转换过程中，通常需要复杂的 ETL 流程，这增加了维护成本和开发难度
+
+使用 Doris 异步物化视图，可以很好的应对上述挑战：
+- 透明改写加速查询：将常用的数据湖查询结果物化到 Doris 内部存储，采用透明改写可有效提升查询性能。
+- 简化分层建模：支持基于数据湖中的表创建物化视图，实现从数据湖到实时数仓的便捷转换，极大简化了数据建模流程。
如下，以 Hive 示例说明：
diff --git
a/i18n/zh-CN/docusaurus-plugin-content-docs/current/query-acceleration/materialized-view/sync-materialized-view.md
b/i18n/zh-CN/docusaurus-plugin-content-docs/current/query-acceleration/materialized-view/sync-materialized-view.md
index 151d9bc1a83..82cacb9b572 100644
---
a/i18n/zh-CN/docusaurus-plugin-content-docs/current/query-acceleration/materialized-view/sync-materialized-view.md
+++
b/i18n/zh-CN/docusaurus-plugin-content-docs/current/query-acceleration/materialized-view/sync-materialized-view.md
@@ -607,20 +607,20 @@ from
## 常见问题
-当创建好物化视图后，如果发现没有匹配的数据，可能是因为物化视图还处于构建过程中。此时，可以使用以下命令来查看物化视图的构建状态：
+1. 当创建好物化视图后，为什么没有改写成功？
+如果发现没有匹配的数据，可能是因为物化视图还处于构建过程中。此时，可以使用以下命令来查看物化视图的构建状态：
```sql
show alter table materialized view from test_db;
```
如果查询结果显示`status`字段不是`FINISHED`，那么需要等待，直到状态变为`FINISHED`后，物化视图才会变得可用。
+2. 从 2.x 升级到 3.0.0，为什么之前同步物化视图不能命中了？
+自 3.0.0 版本起，默认使用基于 plan 结构信息的方式对同步物化视图进行透明改写，控制开关如下，如果发现之前 2.x 能命中但是 3.0.0
不能命中。
+把如下开关关闭，如下开关默认开启。
-## 附录
-
-### 1. 物化视图相关开关介绍
-
-| 开关 | 说明 |
-| --- | --- |
-| `SET enable_sync_mv_cost_based_rewrite = true;` |
是否使用基于结构信息的方式对同步物化视图进行透明改写，默认为 `true`。此属性自 3.0.0 版本起开始支持。 |
\ No newline at end of file
+```sql
+`SET enable_sync_mv_cost_based_rewrite = true;`
+```
\ No newline at end of file
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
