写复杂 SQL 的时候，有没有遇到过这种情况：同一段聚合逻辑，在三个不同的查询里重复出现？改一处就要改三处，维护起来简直要命。
视图（VIEW）就是为了解决这个问题而生的。但视图有个致命缺陷——每次查询都要重新计算。如果底层表有 100 万行数据，每次都从头聚合，性能根本扛不住。
物化视图（Materialized View）是解决方案：把计算结果存下来，下次直接读取。PostgreSQL、Oracle 都支持这个特性。但 DuckDB 呢？
测试结果可能会让你意外。
DuckDB VIEW：零成本的查询复用
VIEW 的本质是一个虚拟表，不存储数据，只存储查询逻辑。每次查询 VIEW 时，DuckDB 都会重新执行定义 VIEW 时的 SQL。
创建 VIEW
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
| import duckdb
conn = duckdb.connect("analytics.db")
# 创建每日销售统计视图
conn.execute("""
CREATE VIEW daily_sales_view AS
SELECT
sale_date,
category,
COUNT(*) AS order_count,
SUM(amount) AS total_amount,
AVG(amount) AS avg_amount
FROM sales_data
GROUP BY sale_date, category
""")
# 查询视图
result = conn.execute("""
SELECT * FROM daily_sales_view
WHERE category = 'Electronics'
ORDER BY total_amount DESC
""").fetchdf()
|
VIEW 的优点很明显：
- 零存储成本：不占用磁盘空间
- 数据始终最新：每次查询都读取最新数据
- 简化复杂 SQL：把重复逻辑封装起来
但缺点也很致命：每次查询都要重新计算。
VIEW 的性能表现
用 100 万行销售数据测试：
1
2
3
4
5
6
7
8
9
10
11
| import time
# 测试 VIEW 查询性能
times = []
for _ in range(10):
start = time.time()
conn.execute("SELECT * FROM daily_sales_view").fetchall()
times.append(time.time() - start)
print(f"VIEW 平均查询时间: {sum(times)/len(times)*1000:.2f}ms")
# 输出：VIEW 平均查询时间: 8.32ms
|
8.32 毫秒看起来还行，但如果这个查询在报表里出现 10 次，就是 83 毫秒。在实时分析场景下，这个延迟已经能感知到了。
重要发现：DuckDB 不支持 MATERIALIZED VIEW
这是整篇文章最关键的发现。
我尝试用标准 SQL 语法创建物化视图：
1
2
3
4
5
| -- 尝试创建物化视图
CREATE MATERIALIZED VIEW test_mv AS
SELECT category, SUM(amount)
FROM sales_data
GROUP BY category;
|
结果报错了：
1
| Parser Error: syntax error at or near "MATERIALIZED"
|
DuckDB 目前没有实现 CREATE MATERIALIZED VIEW 语法。
为什么会这样？DuckDB 的定位是嵌入式分析数据库，追求轻量和快速。物化视图需要复杂的维护机制——增量刷新、依赖追踪、自动更新——这些都会增加系统复杂度。
但物化视图的需求是真实存在的。DuckDB 社区在 GitHub Discussion #3638 里讨论过这个问题，官方暂时没有实现计划。
替代方案：用 CREATE TABLE AS 模拟物化视图
既然没有原生支持，那就自己实现。思路很简单：把查询结果存到一张物理表里。
创建"物化视图"
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
| # 用 CREATE TABLE AS 创建物化视图
conn.execute("""
CREATE TABLE daily_sales_mv AS
SELECT
sale_date,
category,
COUNT(*) AS order_count,
SUM(amount) AS total_amount,
AVG(amount) AS avg_amount
FROM sales_data
GROUP BY sale_date, category
""")
# 查询物化视图（和普通表一样）
result = conn.execute("""
SELECT * FROM daily_sales_mv
WHERE category = 'Electronics'
ORDER BY total_amount DESC
""").fetchdf()
|
性能对比：10.5 倍提升
同样的查询，物化视图的性能提升非常明显：
1
2
3
4
5
6
7
8
9
| # 测试物化视图查询性能
times = []
for _ in range(10):
start = time.time()
conn.execute("SELECT * FROM daily_sales_mv").fetchall()
times.append(time.time() - start)
print(f"物化视图平均查询时间: {sum(times)/len(times)*1000:.2f}ms")
# 输出：物化视图平均查询时间: 0.79ms
|
完整对比数据：
| 指标 | VIEW | 物化视图 (CREATE TABLE AS) | 性能提升 |
|---|
| 简单查询 | 8.32ms | 0.79ms | 10.5x |
| 复杂查询 | 4.64ms | 1.35ms | 3.4x |
| 构建时间 | 0ms（虚拟） | 26.45ms | - |
| 刷新时间 | - | 30.85ms | - |
| 存储空间 | 0（虚拟） | 物理存储 | - |
10.5 倍的性能提升，代价是 26.45 毫秒的构建时间和一些存储空间。
原始表有 100 万行数据，聚合后只剩 140 行。压缩比达到 7142:1，存储成本几乎可以忽略。
物化视图的刷新策略
物化视图不会自动更新。底层表的数据变了，物化视图里的数据还是旧的。必须手动刷新。
全量刷新
最简单的方式：清空重建。
1
2
3
4
5
6
7
8
9
10
11
12
13
| # 全量刷新
conn.execute("DELETE FROM daily_sales_mv")
conn.execute("""
INSERT INTO daily_sales_mv
SELECT
sale_date,
category,
COUNT(*) AS order_count,
SUM(amount) AS total_amount,
AVG(amount) AS avg_amount
FROM sales_data
GROUP BY sale_date, category
""")
|
全量刷新的时间是 30.85 毫秒（DELETE + INSERT）。对于 100 万行数据来说，这个速度非常快。
增量刷新
如果只需要更新最近的数据，可以只刷新部分：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
| # 增量刷新：只刷新最近 7 天
conn.execute("""
DELETE FROM daily_sales_mv
WHERE sale_date >= CURRENT_DATE - INTERVAL '7 days'
""")
conn.execute("""
INSERT INTO daily_sales_mv
SELECT
sale_date,
category,
COUNT(*) AS order_count,
SUM(amount) AS total_amount,
AVG(amount) AS avg_amount
FROM sales_data
WHERE sale_date >= CURRENT_DATE - INTERVAL '7 days'
GROUP BY sale_date, category
""")
|
增量刷新的好处是速度快，但需要表里有时间戳字段。
定时刷新
实际项目里，物化视图的刷新通常是定时的。可以用 cron 或者 Python 调度器：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
| # 用 Python 定时刷新
import schedule
import time
def refresh_materialized_view():
conn.execute("DELETE FROM daily_sales_mv")
conn.execute("""
INSERT INTO daily_sales_mv
SELECT
sale_date, category,
COUNT(*) AS order_count,
SUM(amount) AS total_amount,
AVG(amount) AS avg_amount
FROM sales_data
GROUP BY sale_date, category
""")
print("物化视图已刷新")
# 每小时刷新一次
schedule.every(1).hours.do(refresh_materialized_view)
while True:
schedule.run_pending()
time.sleep(60)
|
VIEW vs 物化视图：如何选择
两种方案各有适用场景，选择的关键在于查询频率和数据实时性要求。
用 VIEW 的场景
- 查询逻辑复杂但不频繁：比如月度报表，一个月只跑一次
- 数据变化频繁，需要实时性：比如实时监控系统，数据必须最新
- 存储空间敏感：磁盘空间紧张，不能浪费
用物化视图的场景
- 重复查询相同的聚合结果：比如仪表盘，每次打开都要看同样的统计
- 查询耗时长（秒级）：复杂聚合查询需要几秒钟，用户等不了
- 可以接受数据延迟：分钟级或小时级的延迟可以接受
- 需要快速响应（毫秒级）：实时交互场景
决策树
1
2
3
4
5
6
7
| 查询频率高吗？
├─ 否 → 用 VIEW（简单、零成本）
└─ 是 → 数据实时性要求高吗？
├─ 是 → 用 VIEW（必须最新）
└─ 否 → 查询耗时长吗？
├─ 否 → 用 VIEW（没必要优化）
└─ 是 → 用物化视图（10x 性能提升）
|
踩坑记录
坑 1：物化视图数据不一致
第一次用物化视图的时候，发现数据对不上。排查了半天，才意识到物化视图不会自动更新。
解决方案：在刷新脚本里加上日志，记录每次刷新的时间和数据量。
1
2
3
4
5
6
7
8
9
10
| def refresh_with_logging():
conn.execute("DELETE FROM daily_sales_mv")
conn.execute("""
INSERT INTO daily_sales_mv
SELECT ... FROM sales_data GROUP BY ...
""")
# 记录刷新日志
count = conn.execute("SELECT COUNT(*) FROM daily_sales_mv").fetchone()[0]
print(f"[{datetime.now()}] 物化视图已刷新，数据量: {count}")
|
坑 2：刷新策略选择错误
一开始用全量刷新，每小时一次。后来数据量上来了，刷新时间从 30 毫秒变成 3 秒，开始影响性能。
解决方案：改成增量刷新，只刷新最近 24 小时的数据。刷新时间降回 50 毫秒。
坑 3：忘记创建索引
物化视图创建后，查询速度确实快了。但加上 WHERE 条件后，性能又掉下来了。
解决方案：给物化视图加索引。
1
2
3
4
5
| # 给物化视图加索引
conn.execute("""
CREATE INDEX idx_mv_category_date
ON daily_sales_mv(category, sale_date)
""")
|
加完索引后，带 WHERE 条件的查询性能提升了 5 倍。
实战案例：电商销售分析
用一个完整的例子演示 VIEW 和物化视图的配合使用。
场景描述
电商平台需要：
- 实时查看今日销售数据（要求最新）
- 每日报表展示月度趋势（可以延迟）
- 仪表盘展示分类统计（频繁查询）
实现方案
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
| # 1. 实时销售数据：用 VIEW
conn.execute("""
CREATE VIEW today_sales_view AS
SELECT
category,
COUNT(*) AS order_count,
SUM(amount) AS total_amount
FROM sales_data
WHERE sale_date = CURRENT_DATE
GROUP BY category
""")
# 2. 月度趋势报表：用物化视图（每天刷新）
conn.execute("""
CREATE TABLE monthly_trends_mv AS
SELECT
strftime(sale_date, '%Y-%m') AS month,
category,
COUNT(*) AS order_count,
SUM(amount) AS total_amount
FROM sales_data
WHERE sale_date >= CURRENT_DATE - INTERVAL '1 year'
GROUP BY month, category
""")
# 3. 仪表盘分类统计：用物化视图（每小时刷新）
conn.execute("""
CREATE TABLE dashboard_category_stats_mv AS
SELECT
category,
COUNT(*) AS total_orders,
SUM(amount) AS total_revenue,
AVG(amount) AS avg_order_value,
COUNT(DISTINCT customer_id) AS unique_customers
FROM sales_data
GROUP BY category
""")
# 给物化视图加索引
conn.execute("CREATE INDEX idx_monthly_month ON monthly_trends_mv(month)")
conn.execute("CREATE INDEX idx_dashboard_category ON dashboard_category_stats_mv(category)")
|
性能对比
| 查询 | VIEW | 物化视图 | 提升 |
|---|
| 今日销售（实时） | 12.5ms | - | - |
| 月度趋势（100万行） | 45.2ms | 1.8ms | 25x |
| 仪表盘统计（频繁） | 28.6ms | 0.9ms | 31x |
实时查询用 VIEW，保证数据最新。频繁查询用物化视图，性能提升 25-31 倍。
总结
DuckDB 虽然没有原生的 MATERIALIZED VIEW 语法，但用 CREATE TABLE AS 可以完美模拟。
关键要点：
- VIEW 适合低频查询：零存储成本，数据始终最新
- 物化视图适合高频查询：10.5 倍性能提升，代价是存储和刷新成本
- 刷新策略很重要：全量刷新简单但慢，增量刷新快但需要时间戳
- 别忘了加索引：物化视图加索引后，带 WHERE 条件的查询性能更好
实际项目里，VIEW 和物化视图通常是配合使用的。实时性要求高的用 VIEW，频繁查询的用物化视图。
物化视图的维护成本不高，但带来的性能提升是实打实的。如果你的 DuckDB 项目里有重复的复杂查询，试试物化视图，可能会有惊喜。
参考资源：
