SQL视图本身不执行汇总，真正按年月汇总依赖视图定义中的GROUP BY和聚合函数；必须显式写出分组逻辑（如DATE_FORMAT(emp_date,'%Y-%m')）并去重，否则结果失真。
SQL 视图本身不执行汇总，它只是保存一条 SELECT 查询；真正做年月汇总的是视图定义里的聚合逻辑。直接在视图里写 GROUP BY DATE_FORMAT(emp_date, '%Y-%m') 或 GROUP BY YEAR(emp_date), MONTH(emp_date) 才能产出按年月聚合的结果。
视图中必须显式包含年月分组逻辑
很多人误以为“建了视图就能自动按年月汇总”，其实不然。视图只是封装查询，如果原查询没写 GROUP BY 和聚合函数，查出来的仍是明细数据。
- 错误写法：视图只写
SELECT emp_date, emp_status FROM emp_temp→ 查出来还是每天一条记录 - 正确写法：必须带聚合，例如
SELECT DATE_FORMAT(emp_date, '%Y-%m') AS ym, COUNT(*) AS total, COUNT(CASE WHEN emp_status = 0 THEN 1 END) AS signed_in FROM emp_temp GROUP BY DATE_FORMAT(emp_date, '%Y-%m') - MySQL 中推荐用
DATE_FORMAT(emp_date, '%Y-%m')，SQL Server 用FORMAT(emp_date, 'yyyy-MM')或YEAR(emp_date) * 100 + MONTH(emp_date) - 注意：视图字段不能是表达式别名（如
ym）直接用于外部ORDER BY，除非在视图定义里明确声明该列名
跨年月数据不准？检查 emp_date 类型和去重逻辑
原始表里一个员工一天可能有多条打卡记录（比如多次签到/修改状态），直接 GROUP BY DATE_FORMAT(emp_date, '%Y-%m') 会把同月所有记录都算进去，导致人数虚高。
- 典型问题：某员工 1 月签到 5 次，视图统计就多算 4 个“签到人次”，而非“签到人数”
- 解决方法：先按员工+日期去重，再按年月聚合 —— 就像知识库示例里用的子查询：
SELECT MAX(emp_date) emp_date, id, emp_status FROM emp_temp GROUP BY id, DATE(emp_date) - 如果
emp_date是DATETIME类型，务必用DATE(emp_date)截断时分秒，否则同一天不同时间会被当成多天 - SQLite 不支持
DATE_FORMAT，得用strftime('%Y-%m', emp_date)
视图性能差？避免在 GROUP BY 里用函数包裹字段
在 GROUP BY DATE_FORMAT(emp_date, '%Y-%m') 这种写法下，MySQL 无法有效使用 emp_date 字段上的索引，全表扫描概率大增。
- 优化方向一：增加生成列（MySQL 5.7+）：
ALTER TABLE emp_temp ADD COLUMN ym CHAR(7) GENERATED ALWAYS AS (DATE_FORMAT(emp_date, '%Y-%m')) STORED，再对ym建索引 - 优化方向二：业务写入时就存年月字段（如
report_month CHAR(7)），视图直接GROUP BY report_month - 不要在视图里嵌套多层子查询做去重+聚合，复杂度高且难维护；优先在基础表上加索引或预计算字段
- PostgreSQL 用户注意：
TO_CHAR(emp_date, 'YYYY-MM')同样无法走索引，建议用date_trunc('month', emp_date)并配合函数索引
权限与可更新性：视图汇总后基本不可 INSERT/UPDATE
含 GROUP BY、聚合函数、去重子查询的视图，在绝大多数数据库中都是只读的。试图 UPDATE 它会报错，比如 MySQL 的 Error 1393: Can not modify more than one base table through a join view。
- 这不是 bug，是 SQL 标准行为：汇总视图没有明确对应单行物理记录
- 如果业务需要“修改某月统计结果”，只能去改源表
emp_temp，然后重新查询视图 —— 别指望视图能反向写回 - 某些场景下（如报表配置页允许人工修正数字），建议另建一张汇总结果表，用定时任务刷新，而不是依赖实时视图
- Oracle 用户注意：
WITH CHECK OPTION对汇总视图无效，别白费劲加
真实项目里，视图按年月汇总最常踩的坑不是语法写错，而是没想清楚“统计口径”——你到底要算人次、人头数、还是事件数？这个逻辑一旦定死，后续所有报表、导出、API 都得跟着它走。别等上线后才发现 1 月缺勤人数比总人数还多。
