视图不支持动态列名，PIVOT需硬编码字段；MySQL无原生PIVOT，应使用CASE WHEN+SUM模拟；新增品类须手动修改SQL；大数据量时需在(sale_date,product)建联合索引；动态需求应交由应用层或BI工具处理。
视图里不能用动态列名，PIVOT 必须写死字段
SQL 视图本质是预定义的查询，不支持运行时生成列名。想把 sales_log 这类按日期+产品+金额逐行记录的明细表转成「每列一个产品、每行一个日期」的透视结构，必须明确列出所有要展开的产品。比如你只有 'iPhone'、'Mac'、'iPad' 三个产品，就得在 PIVOT 子句里硬编码它们：
SELECT sale_date,
[iPhone], [Mac], [iPad]
FROM (SELECT sale_date, product, amount FROM sales_log) AS src
PIVOT (SUM(amount) FOR product IN ([iPhone], [Mac], [iPad])) AS pvt;
一旦新增了 'AirPods'，这个视图就查不出新产品的列——得手动改 DDL 并重新创建视图。
MySQL 用户别找 PIVOT，用条件聚合更实际
MySQL 直到 8.0.23 都没原生 PIVOT，强行套 SQL Server 写法会报错 ERROR 1064 (42000)。正确做法是用 CASE WHEN + SUM 模拟：
SELECT sale_date,
SUM(CASE WHEN product = 'iPhone' THEN amount ELSE 0 END) AS iPhone,
SUM(CASE WHEN product = 'Mac' THEN amount ELSE 0 END) AS Mac,
SUM(CASE WHEN product = 'iPad' THEN amount ELSE 0 END) AS iPad
FROM sales_log
GROUP BY sale_date;
注意点：
-
ELSE 0不能省，否则遇到非匹配行会返回NULL，导致整列聚合结果为NULL - 必须加
GROUP BY，否则每行都算一遍，结果重复且无意义 - 列名用反引号包裹（如
`AirPods`）可避免关键字冲突，但无法解决新增品类需改代码的问题
实时性取决于底层表，视图本身不缓存数据
视图只是保存 SELECT 语句文本，每次查询都会实时执行背后的逻辑。所以只要 sales_log 表有新插入或更新，视图查出来就是最新透视结果——这点不用额外配置。但要注意：
- 如果明细表数据量大（比如千万级），每次查视图都全表扫描 + 分组聚合，响应可能变慢
- 没有索引支撑时，
GROUP BY sale_date, product组合查询效率低，建议在(sale_date, product)上建联合索引 - 某些数据库（如 PostgreSQL）支持物化视图，但 MySQL 和多数云厂商默认视图仍是即时计算，别误以为“视图=缓存”
真正需要动态列时，视图不是解法
当产品种类每周都在变，或者前端要求“自动识别所有 product 值并生成列”，SQL 视图从设计上就不适用。这时候该换思路：
- 应用层做 pivot：查出
SELECT sale_date, product, amount FROM sales_log，用 Python 的pandas.pivot_table()或 JS 的Array.reduce()动态组装 - 用 BI 工具直连明细表：Tableau / Power BI 内置透视功能，拖拽即可，无需 SQL 层硬编码
- 定时任务生成新视图：写个脚本查
SELECT DISTINCT product FROM sales_log，拼出带完整列名的 DDL，再DROP+CREATE VIEW，但运维成本高，且中间存在窗口期
硬靠视图扛动态维度，最后往往卡在 DDL 变更权限、上线流程和跨环境一致性上。
