物化视图仅在移除JOIN和聚合时才提速；PostgreSQL 12+和Oracle原生支持，MySQL等不识别MATERIALIZED语法；需建唯一索引才能并发刷新；必须预聚合、补零、字段类型一致。
物化视图不是“开关一开就提速”的银弹，它只在你明确把JOIN和聚合从查询路径里移除时才真正生效。其他所有写法——比如带JOIN的普通视图、CTE不加MATERIALIZED、或MySQL里照搬CREATE MATERIALIZED VIEW——都会失败或白忙。
确认数据库是否原生支持CREATE MATERIALIZED VIEW
PostgreSQL 12+ 和 Oracle 支持该语法；MySQL、SQL Server、SQLite 官方根本不识别MATERIALIZED关键字，执行直接报错ERROR: syntax error at or near "MATERIALIZED"。别跳过这步：先运行SELECT version();，再查对应版本文档。误判环境会导致后续所有SQL卡在解析阶段。
- PostgreSQL：可用
CONCURRENTLY刷新，但必须先建唯一索引 - Oracle：语法为
CREATE MATERIALIZED VIEW ... REFRESH ON COMMIT，机制完全不同 - MySQL：只能用
CREATE TABLE AS SELECT+ 定时任务模拟，没有并发刷新能力
用REFRESH MATERIALIZED VIEW CONCURRENTLY避免锁表
默认REFRESH MATERIALIZED VIEW会阻塞所有读请求，且全量重建；而CONCURRENTLY模式只更新差异行，前提是物化视图上已有唯一索引覆盖所有JOIN键和业务主键。
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
- 必须提前建索引，例如：
CREATE UNIQUE INDEX idx_mv_user_order ON mv_user_order (user_id, order_id) - 索引字段顺序要和JOIN条件顺序一致，否则仍会报错
cannot refresh ... concurrently because it does not have a unique index -
CONCURRENTLY不能放在事务块中（即不能在BEGIN; ... COMMIT;里调用） - 若底层源表无主键或更新频繁，可能因冲突重试失败，需捕获SQLSTATE
'55000'并退化为普通刷新
在JOIN前完成预聚合，而非依赖物化视图本身
即使用了物化视图，如果里面还是写SELECT * FROM a JOIN b JOIN c，中间结果集爆炸问题照旧。真正有效的做法是：在物化视图定义里就把聚合做完，让最终表只存维度+指标，而不是原始关联行。
- 正确示例：
CREATE MATERIALIZED VIEW mv_user_monthly AS SELECT u.id, SUM(o.amount) FROM users u JOIN orders o ON u.id = o.user_id WHERE o.created_at >= current_date - interval '30 days' GROUP BY u.id - 错误倾向：把物化视图当成“大宽表”来建，字段堆满用户、订单、商品信息，反而放大存储和刷新开销
- 预聚合后必须补零：
LEFT JOIN mv_user_monthly ON u.id = mv.user_id要搭配COALESCE(mv.total_spent, 0)，否则无订单用户直接消失 - 确保JOIN字段类型严格一致（如都是
BIGINT），任何隐式转换都会让索引失效，预聚合白做
最难的不是建出物化视图，而是让每张源表在刷新时只触达必要行数——索引字段顺序、唯一约束覆盖范围、聚合过滤下推位置，这三个点漏掉任何一个，性能就断崖下跌。
