MySQL存储过程实现数据同比环比计算与统计逻辑封装

MySQL存储过程计算同比环比时需规避YEAR()/MONTH()函数陷阱，改用DATE_SUB进行日期对齐；SUM()聚合必须用COALESCE处理空值；SELECT ... INTO赋值前应验证数据存在性；同比环比计算分母需用CASE WHEN防护零或负值。

存储过程中直接使用 YEAR() 与 MONTH() 函数可能导致逻辑错误

在MySQL存储过程开发中，于WHERE条件中依赖YEAR()或MONTH()函数进行跨年或跨月判断，是一个常见的设计缺陷。例如，使用YEAR(date) = year - 1看似合理，但当存储过程在一月份执行时，表达式month - 1将得到0，导致条件MONTH(date) = 0永远无法成立。其后果是查询结果为空，使得previousTotal等变量被赋值为NULL，进而引发后续除法运算报出“Division by zero”错误或静默返回NULL，致使整个统计逻辑失效。

推荐采用日期运算函数来精确对齐时间粒度，从而避免边界问题：

• 同比计算：使用DATE_SUB(date, INTERVAL 1 YEAR)来获取上一年的对应日期，并基于此进行数据过滤与分组，而非直接对年份数值进行加减。
• 环比计算：同理，应使用DATE_SUB(date, INTERVAL 1 MONTH)来准确定位上一个月的日期范围，这比依赖MONTH() - 1更为可靠。
• 空值防护：此为关键步骤，务必为SUM()聚合函数搭配COALESCE(..., 0)。否则，若求和字段中存在NULL，整个增长率计算结果将变为NULL，导致统计失败。

使用 SELECT ... INTO 进行变量赋值前未校验数据存在性

另一个典型疏漏发生在通过SELECT ... INTO为变量赋值时。例如，执行SELECT SUM(amount) INTO currentTotal FROM sales WHERE ...，如果WHERE条件未匹配到任何数据行，那么currentTotal变量不会被设置为0，而是NULL。后续的计算，无论是NULL - 100还是NULL / 100，结果都将保持为NULL。最终，存储过程可能输出一系列空值，且由于语法无误，此类问题排查起来极为困难。

为确保健壮性，应采用以下安全写法：

• 子查询合并处理：直接在查询中应用(SELECT COALESCE(SUM(amount), 0) FROM sales WHERE ...)，一次性完成求和与空值转换。
• 先计数后取值：先执行SELECT COUNT(*) INTO row_count FROM sales WHERE ...，依据row_count的值决定是否进行求和操作，逻辑更为清晰。
• 优化策略：单次聚合查询：更推荐的做法是通过一次聚合查询，同时获取当前值、同比值与环比值。这不仅能避免多次SELECT ... INTO带来的性能损耗与状态不一致风险，也使代码结构更加紧凑和健壮。

同比环比计算中分母为零或负数时缺乏防护机制

计算增长率的经典公式(current - previous) / previous * 100潜藏两大风险：其一，当previous（即上期数值）为0时，除法运算将直接失败；其二，当previous为负数时（例如上期业绩为亏损），计算得出的增长率符号可能完全失真，严重误导业务决策。例如，业绩从-50万改善至30万本是显著提升，但公式计算结果却可能显示为-160%，这与实际情况相悖。

因此，在生产环境的存储过程中，必须引入保护逻辑：

• 应用CASE WHEN分支：对同比/环比结果统一采用CASE WHEN previousTotal = 0 THEN NULL WHEN previousTotal < 0 THEN ... ELSE ... END此类结构进行判断与处理。
• 制定明确策略：常见的处理方式包括：当分母为零时，返回NULL或特定标记如'N/A'；当分母为负时，可考虑使用绝对值计算差额，或单独标记为“基期为负，需专项分析”。
• 后端拦截原则：务必牢记，此类涉及数据完整性与计算逻辑正确性的问题，应在存储过程这一数据层彻底解决，而不应依赖前端JavaScript或应用层代码进行事后补救。

采用 JOIN 替代多次独立查询以提升稳定性与性能

回顾初始方案：分别执行三次独立查询（本期、上年同期、上期），每次查询都涉及全表扫描与函数计算，性能开销巨大。更重要的是，在事务中多次读取同一张表，可能在并发写入场景下导致三次查询所见数据状态不一致，从而计算出相互矛盾的结果。

转换思路，采用单次聚合配合表连接，方案更为优雅与稳定：

SELECT
  curr.yymm AS period,
  curr.total AS current_total,
  last_yr.total AS yoy_total,
  COALESCE(ROUND((curr.total - last_yr.total) / NULLIF(last_yr.total, 0) * 100, 2), NULL) AS yoy_rate,
  last_mth.total AS mom_total,
  COALESCE(ROUND((curr.total - last_mth.total) / NULLIF(last_mth.total, 0) * 100, 2), NULL) AS mom_rate
FROM (
  SELECT DATE_FORMAT(date, '%Y-%m') yymm, SUM(amount) total
  FROM sales GROUP BY DATE_FORMAT(date, '%Y-%m')
) curr
LEFT JOIN (
  SELECT DATE_FORMAT(DATE_SUB(date, INTERVAL 1 YEAR), '%Y-%m') yymm, SUM(amount) total
  FROM sales GROUP BY DATE_FORMAT(DATE_SUB(date, INTERVAL 1 YEAR), '%Y-%m')
) last_yr ON curr.yymm = last_yr.yymm
LEFT JOIN (
  SELECT DATE_FORMAT(DATE_SUB(date, INTERVAL 1 MONTH), '%Y-%m') yymm, SUM(amount) total
  FROM sales GROUP BY DATE_FORMAT(DATE_SUB(date, INTERVAL 1 MONTH), '%Y-%m')
) last_mth ON curr.yymm = last_mth.yymm;

此写法的优势显而易见：它天然规避了月份越界、空值传递和重复数据扫描的问题。从性能优化角度，仅需在date字段上建立合适索引，即可高效支撑所有基于日期的计算与连接操作。

归根结底，真正的挑战并非编写一段在测试环境中可运行的SQL，而是确保该逻辑在面对数据量激增、跨年跨月切换、基期数据为零、财务数据冲正调整等各种边缘场景时，依然能够输出稳定且业务可解释的结果。因此，切勿为节省几行COALESCE和NULLIF的代码，而为系统埋下长期的隐患。