MySQL 8.0+ 可用 LAG() 和窗口函数高效计算占比、同比、环比，5.x 需自连接或变量，性能差；占比分全局与分组，需正确使用 SUM() OVER()；环比用 LAG() 需处理空值和排序；同比推荐 LAG(...,12) 而非年份减法；分母为0时须用 CASE 显式兜底。
MySQL 8.0+ 直接用 LAG() 和窗口聚合就能算占比、同比、环比，不用嵌套子查询；5.x 版本必须靠自连接或变量模拟，性能差、易出错。
用 SUM() OVER() 算占比，注意分母是否要全局 or 分组
占比本质是「部分 / 总体 × 100%」，但“总体”范围决定结果含义：
- 全局占比：分母用
SUM(sale_amount) OVER()，所有行共享同一个总和 - 分组占比（如每月内各产品占比）：分母加
PARTITION BY yyyy_mm，即SUM(sale_amount) OVER(PARTITION BY yyyy_mm) - 别直接用
AVG()或COUNT()当分母——它们不等于“该组总销售额”
示例（按月分组内各产品的销售占比）：
SELECT
DATE_FORMAT(orderdate, '%Y-%m') AS yyyy_mm,
product_name,
SUM(priceEach * quantityOrdered) AS sale_amount,
ROUND(
SUM(priceEach * quantityOrdered) * 100.0 /
SUM(SUM(priceEach * quantityOrdered)) OVER(PARTITION BY DATE_FORMAT(orderdate, '%Y-%m')),
2
) AS pct_in_month
FROM orders o
JOIN orderdetails od ON o.orderNumber = od.orderNumber
JOIN products p ON od.productCode = p.productCode
GROUP BY yyyy_mm, product_name;用 LAG() 算环比，重点在 ORDER BY 和空值处理
LAG(sale_amount) OVER(ORDER BY yyyy_mm) 是核心，但容易踩三个坑：
- 时间字段必须能严格排序：用
DATE_FORMAT(orderdate, '%Y-%m')比直接MONTH(orderdate)安全，否则 2025-12 和 2026-01 会排错 - 首行的上期值一定是
NULL，除零错误会直接让整列变NULL，必须用IFNULL(..., 0)或CASE WHEN拦截 - 如果某月无数据（比如 2026-03 缺失），
LAG()会跳到再上月（2026-02 → 2026-01），不是“断层补 0”，这是正常行为，不是 bug
安全写法示例（带增长率）：
MySQL（Linux）
下载
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
SELECT
yyyy_mm,
sale_amount,
IFNULL(LAG(sale_amount) OVER(ORDER BY yyyy_mm), 0) AS last_month,
CASE
WHEN LAG(sale_amount) OVER(ORDER BY yyyy_mm) = 0 THEN NULL
ELSE ROUND((sale_amount - LAG(sale_amount) OVER(ORDER BY yyyy_mm)) * 100.0 / LAG(sale_amount) OVER(ORDER BY yyyy_mm), 2)
END AS mom_pct
FROM (
SELECT DATE_FORMAT(orderdate, '%Y-%m') AS yyyy_mm, SUM(priceEach * quantityOrdered) AS sale_amount
FROM orders o JOIN orderdetails od ON o.orderNumber = od.orderNumber
GROUP BY yyyy_mm
) t;用 LAG(..., 12) 算同比，月份对齐比年份减法更可靠
同比不是简单 “YEAR(orderdate) - 1”，而是“同一月的去年值”。LAG(sale_amount, 12) 更准，前提是你按月聚合且数据连续：
- 必须确保结果集已按
yyyy_mm严格升序排列，否则偏移量 12 会错位 - 如果数据只有 2025-01 到 2026-06，那么 2025-01 的
LAG(..., 12)是NULL，合理 - 别用
LEFT JOIN去关联去年同月——在 8.0+ 环境下纯属倒退，性能差且逻辑绕
示例（同比销售额与增长率）：
SELECT
yyyy_mm,
sale_amount,
LAG(sale_amount, 12) OVER(ORDER BY yyyy_mm) AS last_year_same_month,
CASE
WHEN LAG(sale_amount, 12) OVER(ORDER BY yyyy_mm) = 0 THEN NULL
ELSE ROUND((sale_amount - LAG(sale_amount, 12) OVER(ORDER BY yyyy_mm)) * 100.0 / LAG(sale_amount, 12) OVER(ORDER BY yyyy_mm), 2)
END AS yoy_pct
FROM (
SELECT DATE_FORMAT(orderdate, '%Y-%m') AS yyyy_mm, SUM(priceEach * quantityOrdered) AS sale_amount
FROM orders o JOIN orderdetails od ON o.orderNumber = od.orderNumber
GROUP BY yyyy_mm
) t;最常被忽略的一点：环比/同比的分母为 0 时，MySQL 不报错但结果为 NULL，而业务报表往往要求显示“—”或“0%”，这必须在应用层或 SQL 中用 CASE 显式兜底，不能依赖默认行为。
