视图本身不能自动按月汇总，必须在定义中用date_trunc（postgresql）或date_format（mysql）等函数归一化日期为年月粒度再group by，且需显式过滤空值、避免非确定性函数，才能确保可复用、可筛选、可索引。
视图本身不能自动按月汇总，必须依赖底层数据的时间字段
SQL 视图只是保存的查询语句，不存储数据，也不具备定时执行能力。所谓“按月自动汇总”，实际是指：视图定义中用 GROUP BY 对日期字段做年月分组，并用 DATE_TRUNC('month', ...) 或 EXTRACT(YEAR FROM ...) + EXTRACT(MONTH FROM ...) 等方式归一化时间粒度。是否“自动”，取决于你查视图时传入的日期范围——它不会自己跳到最新月份。
常见错误是以为建好视图就万事大吉，结果发现历史数据全在、当月数据没更新——其实不是视图问题，而是源表没写入当月销售记录，或查询时没加 WHERE order_date >= '2024-01-01' 这类过滤条件。
- PostgreSQL 推荐用
DATE_TRUNC('month', order_date)，返回带时分秒的月初时间（如'2024-04-01 00:00:00'），便于后续范围查询 - MySQL 要用
DATE_FORMAT(order_date, '%Y-%m-01')或STR_TO_DATE(CONCAT(YEAR(order_date), '-', MONTH(order_date), '-01'), '%Y-%m-%d') - SQL Server 常用
DATEFROMPARTS(YEAR(order_date), MONTH(order_date), 1) - 别直接
GROUP BY YEAR(order_date), MONTH(order_date)——这样无法利用日期索引，性能差，且排序结果不是自然月序（比如 2023-12 会排在 2024-01 前面但跨年）
创建可复用的销售月报视图要包含哪些关键字段
一个实用的月度销售视图，至少得暴露可过滤、可排序、可聚合的基础维度，而不是只塞几个 SUM() 就完事。否则下游报表或 BI 工具很难灵活下钻。
典型字段组合示例（以 PostgreSQL 为例）：
CREATE VIEW sales_monthly_summary AS
SELECT
DATE_TRUNC('month', order_date) AS month_start,
EXTRACT(YEAR FROM order_date) AS sales_year,
EXTRACT(MONTH FROM order_date) AS sales_month,
product_category,
COUNT(*) AS order_count,
SUM(quantity) AS total_quantity,
SUM(amount) AS total_amount,
AVG(amount) AS avg_order_value
FROM orders o
JOIN order_items oi ON o.order_id = oi.order_id
WHERE order_date IS NOT NULL
GROUP BY DATE_TRUNC('month', order_date), product_category;
-
month_start是核心——既是分组依据，也是后续WHERE month_start >= '2024-01-01'的筛选键 - 显式拆出
sales_year和sales_month方便按年份筛选或前端展示“2024 年 4 月”这类格式 - 务必在
WHERE子句里过滤掉空日期，避免NULL被归进某个月份组（不同数据库对NULL在GROUP BY中的行为不一致） - 如果源表有状态字段（如
order_status = 'shipped'），必须在这里过滤，否则未发货订单也会计入销售额
为什么不能在视图里写 WHERE date >= CURRENT_DATE - INTERVAL '3 months'
因为大多数数据库（PostgreSQL、SQL Server、Oracle）在创建视图时，不允许使用非确定性函数作为 WHERE 条件——CURRENT_DATE、NOW()、GETDATE() 都属于运行时才计算的值，会导致视图定义不稳定，某些客户端或 BI 工具可能缓存旧结果，或在物化视图场景下根本无法刷新。
正确做法是把动态过滤留给查询视图的人：
- 查最近三个月：
SELECT * FROM sales_monthly_summary WHERE month_start >= DATE_TRUNC('month', CURRENT_DATE) - INTERVAL '3 months'; - 查指定年份：
SELECT * FROM sales_monthly_summary WHERE sales_year = 2024; - BI 工具连接时，通常支持参数化查询，把
${start_month}替换为具体值即可
硬编码动态条件不仅让视图失去通用性，还会掩盖真实数据范围——别人复用时可能根本意识不到这个限制。
MySQL 用户注意：DATE_FORMAT 返回字符串，GROUP BY 会隐式类型转换
MySQL 的 DATE_FORMAT(order_date, '%Y-%m') 返回的是字符串（如 '2024-04'），而字符串分组在大数据量下比日期类型慢；更麻烦的是，如果你后续想用 WHERE month_str >= '2024-01'，它走不了索引，而且字符串比较逻辑和日期逻辑不一致（比如 '2024-10' 成立，但日期上显然不对）。
稳妥方案是用 STR_TO_DATE() 构造月初日期：
SELECT STR_TO_DATE(CONCAT(YEAR(order_date), '-', MONTH(order_date), '-01'), '%Y-%m-%d') AS month_start, ... GROUP BY STR_TO_DATE(CONCAT(YEAR(order_date), '-', MONTH(order_date), '-01'), '%Y-%m-%d');
- 这样
month_start是DATE类型，能走索引，也能正确参与日期运算 - 避免用
CONCAT(YEAR(...), '-', MONTH(...))直接分组——看起来简洁，但本质还是字符串，隐患同上 - 如果 MySQL 版本 ≥ 8.0，也可用
MAKEDATE(YEAR(order_date), 1) + INTERVAL (MONTH(order_date)-1) MONTH，语义更清晰
真正难的从来不是写出能跑的 SQL，而是写出别人接手时不踩坑、业务变化时不用重写的 SQL。月报视图里那个 month_start 字段，决定了后续所有扩展的自由度。
