做报表的时候，最烦的一件事是什么？不是SQL写不出来，而是查出来的数据缺行。时间序列上少一天、少一个月，图表就断一截，前端画图的人跑来问你“这天是没数据还是系统挂了”。你说没数据吧，老板看着图觉得业务暴跌；你说系统挂了吧，运维又得背锅。其实问题很简单：数据库里没有这一天的记录，你直接GROUP BY日期，自然不会出现这一行。要解决就得在SQL层面把缺失的日期或序号补上，对应的值填0。这就是所谓的数据补零。
我做数据分析和报表开发这么些年，补零这个需求几乎每个项目都会遇到，而且不同数据库的写法差异很大，坑也不少。这篇就把SQL补零这件事彻底讲透，从最基础的数值格式化补零，到时间序列缺失补零的完整方案，再到性能优化和常见坑位，一次性说清楚。
1. 数据补零到底是什么场景
先说清楚，SQL里的“补零”其实是两类完全不同的需求，很多人混在一起问，导致网上答案对不上号。
1.1 数值格式化补零：把1变成001
第一类是数值格式化。比如订单编号要统一成6位，商品编码不足位数前面补零，或者导出Excel时编号列要保持等宽。这类需求本质上是字符串处理，跟数据缺失没关系，只是把值从1显示成001。
典型写法就是LPAD、RIGHT这类函数。但不同数据库的函数名不一样，稍不注意就会写错。比如在MySQL里是LPAD(字段, 3, '0')，在SQL Server里LPAD不存在，得用REPLICATE拼或者FORMAT函数。很多从MySQL转SQL Server的人在这里卡半天。
1.2 时序缺失补零：报表不能缺天缺月
第二类是真正的“缺数据补零”，也是本文的重点。业务表里没有某一天的记录，但报表需要连续的时间轴，缺失的日期要补出来，指标值填0。
举个例子：订单表里3月5日一单都没有，如果你直接按天分组统计，结果里就没有3月5日这一行。但报表要展示3月1日到3月7日的连续趋势，3月5日必须出现，订单数显示0。这个0在数据库里根本不存在，纯粹是报表需要“造”出来的。
我在实际项目里见过不少同事用程序端硬补：先查数据库，拿到有数据的日期，再到Python或Java里循环把缺的日期填0。这样做虽然能出结果，但有几个问题：一是报表SQL要返回全量数据，数据量大时网络传输浪费严重；二是分页和排序处理麻烦；三是如果多个报表都要补零，每个程序都要写一套逻辑，维护成本高。直接在SQL里把补零这件事做掉，是最干净的做法。
2. 数值格式化补零：从1到001的几种写法
先解决简单的，但简单归简单，坑也不少。
2.1 MySQL / MariaDB的LPAD方案
MySQL里补零最直接的是LPAD函数，语法是LPAD(str, len, padstr)，意思是把str用padstr从左边补到len长度。
SELECT LPAD(CAST(id AS CHAR), 6, '0') AS order_no FROM orders;这里有个细节：LPAD的第一个参数必须是字符串，如果id是数字类型，必须先用CAST转成CHAR，否则MySQL会做隐式转换，结果可能不是你想要的。我见过有人直接写LPAD(id, 6, '0')，当id是INT类型时看似没报错，但实际转换逻辑不透明，建议显式CAST。
如果你要补零的字段本身可能为空，还要注意NULL值。LPAD(NULL, 6, '0')的结果是NULL，不是'000000'，这时候要先用COALESCE处理：
SELECT LPAD(COALESCE(code, ''), 6, '0') AS new_code FROM products;这样如果code为NULL，结果是'000000'，符合大多数业务预期。
2.2 SQL Server的REPLICATE与FORMAT
SQL Server没有LPAD，最传统的写法是REPLICATE拼接：
SELECT RIGHT(REPLICATE('0', 6) + CAST(id AS VARCHAR(10)), 6) AS order_no FROM orders;这个写法的原理：先拼6个0在前面，再用RIGHT取右边6位。如果id是123，拼接后是'000000123'，取右边6位就是'000123'，效果正好。
SQL Server 2012以上版本还可以用FORMAT函数：
SELECT FORMAT(id, 'D6') AS order_no FROM orders;FORMAT写法更简洁，但性能比REPLICATE方式差很多，因为它走的是.NET格式化。数据量小无所谓，几百万行的表建议还是用REPLICATE方案。
2.3 PostgreSQL和Oracle的差异
PostgreSQL和MySQL一样，也支持LPAD函数，写法基本一致：
SELECT LPAD(id::TEXT, 6, '0') FROM orders;Oracle同样有LPAD，但去零补零还有一个更优雅的写法，就是TO_CHAR的数字格式控制：
SELECT TO_CHAR(id, 'FM000000') AS order_no FROM orders;这里的FM表示去掉结果里的前导空格，000000表示6位数字，不足则左边补零。Oracle的TO_CHAR格式化功能强大到能直接补零，不需要拼字符串。不过FM格式对于负号处理有点特殊，要留意一下。
数值格式化补零不复杂，核心就是记住各数据库的函数差异。建议做报表开发时把这几种写法整理成自己的代码片段，换数据库时直接查。
3. 时间序列缺失补零：报表不再缺天缺月
接下来是重头戏：时序数据补零。这也是“SQL实现数据补零”最常见的需求场景。核心思路可以用一句话概括：先造出完整的时间序列，再与业务表做左连接，缺失的值用COALESCE补0。
3.1 核心思路：先造序，再关联
为什么直接GROUP BY会缺行？因为GROUP BY是基于表里的实际数据分组的，表里没有3月5日的记录，分组结果里就没有这一组。所以补零的第一步是“无中生有”——生成一段完整的日期序列，让它作为驱动表，再去关联业务数据。
打个比方：你要统计一条街上每家店铺每天多少人进店，但有些店某天没开门，你手里只有开门那几天的记录。要画出连续一周的客流图，你得先把这一周的日期一一列出来，再逐个店匹配，没开门的记0。SQL里的做法就是这个逻辑。
实现日期序列的方式主要有两种：递归CTE和数字辅助表。下面分别讲。
3.2 递归CTE造日期序列（MySQL 8.0 / SQL Server / PostgreSQL通用）
递归CTE是生成连续日期最灵活的方式。以MySQL 8.0为例，生成2024年3月1日到3月7日的日期序列：
WITH RECURSIVE date_seq AS ( SELECT DATE('2024-03-01') AS d UNION ALL SELECT d + INTERVAL 1 DAY FROM date_seq WHERE d < DATE('2024-03-07') ) SELECT d FROM date_seq;这段SQL的逻辑：初始查询返回第一个日期，递归部分每次加1天，直到超过结束日期为止。执行结果就是3月1日到7日共7行。
SQL Server和PostgreSQL的递归CTE语法略有不同，SQL Server用DATEADD，PostgreSQL用d + 1：
-- SQL Server WITH date_seq AS ( SELECT CAST('2024-03-01' AS DATE) AS d UNION ALL SELECT DATEADD(DAY, 1, d) FROM date_seq WHERE d < '2024-03-07' ) SELECT d FROM date_seq;-- PostgreSQL WITH RECURSIVE date_seq AS ( SELECT DATE('2024-03-01') AS d UNION ALL SELECT d + 1 FROM date_seq WHERE d < DATE('2024-03-07') ) SELECT d FROM date_seq;拿到日期序列后，再和订单表做LEFT JOIN，完整的补零SQL就出来了：
WITH RECURSIVE date_seq AS ( SELECT DATE('2024-03-01') AS d UNION ALL SELECT d + INTERVAL 1 DAY FROM date_seq WHERE d < DATE('2024-03-07') ) SELECT ds.d AS order_date, COALESCE(SUM(o.amount), 0) AS total_amount FROM date_seq ds LEFT JOIN orders o ON o.order_date = ds.d GROUP BY ds.d ORDER BY ds.d;这里有两个关键点。第一，COUNT(o.id) 不能用 COALESCE(COUNT(o.id), 0) 包，因为COUNT本身不管有没有匹配行，都会返回数字，COUNT(o.id)在无匹配时结果是0，已经是0了，但注意如果写成COUNT(*)就会把补出来的日期行也计成1，结果大错特错。所以统计类聚合函数要区分：SUM和AVG需要COALESCE包裹，COUNT不需要，但要小心COUNT的统计对象。第二，GROUP BY一定用ds.d而不是o.order_date，因为后者在无匹配时为NULL，分组合并会出问题。
3.3 用数字辅助表替代递归，避开性能问题
递归CTE虽然好用，但在某些场景下有性能隐患，尤其是生成几百上千天的序列时，递归的每一层都是独立查询，大数据量下可能比较慢。另一个更工程化的方案是“数字辅助表”。
思路很简单：在一张只有一列数字的辅助表里，预先生成0到N的自然数。需要日期序列时，用起始日期加数字即可：
-- 先建一张数字表，0到9999 CREATE TABLE seq_num (n INT PRIMARY KEY); -- 生成2024年全年每天 SELECT DATE('2024-01-01') + INTERVAL n DAY AS d FROM seq_num WHERE n < 366;有的人可能觉得建辅助表麻烦，但实际效果很好，尤其是在数据仓库里。因为数字表本身很小，且连接条件简单，性能非常稳定。我见过不少生产系统里就常驻一张num_10000表，除了生成日期，还能用来做行转列、拆分字符串等各种操作，属于一劳永逸的工具表。
MySQL 8.0以上的版本也可以利用递归CTE配合内联生成序列，但要注意递归深度限制，后面会专门讲。
3.4 按小时补零、按周补零的变形
补零不只限于按天。按小时统计的监控报表、按周统计的运营报表同样缺数据。核心原理一样，只是时间序列的粒度不同。
按小时补零，日期序列的生成就变成：
WITH RECURSIVE hour_seq AS ( SELECT DATE_FORMAT('2024-03-01 00:00:00', '%Y-%m-%d %H:00:00') AS h UNION ALL SELECT h + INTERVAL 1 HOUR FROM hour_seq WHERE h < '2024-03-02 00:00:00' ) SELECT h FROM hour_seq;如果业务表里记录的是具体时间点，关联时要把业务时间先截断到小时再匹配。很多人在这里直接LEFT JOIN，发现匹配不上，就是因为业务时间是2024-03-01 08:30:15，而序列里是08:00:00，根本对不上。先用DATE_FORMAT或DATE_TRUNC截断再关联：
SELECT hs.h, COALESCE(SUM(o.amount), 0) AS total_amount FROM hour_seq hs LEFT JOIN orders o ON DATE_FORMAT(o.order_time, '%Y-%m-%d %H:00:00') = hs.h GROUP BY hs.h ORDER BY hs.h;按周补零稍微复杂一点，因为一周的起始日各数据库定义不同，MySQL默认周日为一周开始。一般建议先指定一个基准日期，比如从某周的周一开始生成：
WITH RECURSIVE week_seq AS ( SELECT DATE('2024-03-04') AS w -- 周一 UNION ALL SELECT w + INTERVAL 7 DAY FROM week_seq WHERE w < '2024-04-01' ) SELECT w FROM week_seq;关联业务表时，同样把订单日期换算到该周的周一日期，再相等匹配。
3.5 跨数据库的可行性与兼容性
这一段必须单独讲，因为很多人是从SQL Server 2008或MySQL 5.7这种老版本环境里做开发。递归CTE在MySQL 5.7及以下版本完全不支持，在SQL Server 2005及以上版本才支持。
老版本MySQL没有递归CTE，又不想建辅助表，怎么办？可以借助系统表枚举数字。比如MySQL 5.7里，用information_schema.columns拼数字：
SELECT DATE('2024-03-01') + INTERVAL seq.n DAY AS d FROM ( SELECT @rownum := @rownum + 1 AS n FROM information_schema.columns a, information_schema.columns b, (SELECT @rownum := -1) r LIMIT 30 ) seq;这种方式看起来很野路子，但在老环境里确实能用。LIMIT要控制好范围，别把整个information_schema都枚举一遍，性能会很难看。另外要注意变量的初始化，写成SELECT @rownum := -1保证第一条记录从0开始。
Oracle没有这个问题，它的CONNECT BY语法天生适合生成序列：
SELECT DATE '2024-03-01' + LEVEL - 1 AS d FROM dual CONNECT BY LEVEL <= 7;反过来，MySQL直到8.0.11才支持窗口函数，Oracle和SQL Server早就有了。所以做跨数据库方案设计时，先确认版本再选技术方案，这是最容易踩的坑。
4. 窗口函数如何参与补零
补零不只是把缺失行补出来那么简单。补完之后往往还要算环比、同比、累计值，这时候窗口函数就派上用场了。很多人补零生成了完整序列，却在计算环比时发现结果还是不对，原因就出在窗口函数的计算顺序上。
4.1 补零后再算环比和同比
环比的意思是跟上一个周期比，典型SQL是用LAG函数取上一行的值：
WITH RECURSIVE date_seq AS (...), sales AS ( SELECT ds.d AS order_date, COALESCE(SUM(o.amount), 0) AS total_amount FROM date_seq ds LEFT JOIN orders o ON o.order_date = ds.d GROUP BY ds.d ) SELECT order_date, total_amount, LAG(total_amount, 1) OVER (ORDER BY order_date) AS prev_amount, CASE WHEN LAG(total_amount, 1) OVER (ORDER BY order_date) = 0 THEN NULL ELSE total_amount - LAG(total_amount, 1) OVER (ORDER BY order_date) END AS diff_amount FROM sales ORDER BY order_date;这里一定要先补零生成sales子查询，再在外层用LAG。如果你在原始业务表上直接LAG，你会发现3月5日没数据，那么3月6日计算环比时，LAG取到的是3月4日的数据，跳过了3月5日，环比结果就错了。这是补零与窗口函数结合时最典型的错误。
同比也是同理。按年同比时，如果缺了去年同月的数据，也要先在完整序列里把去年各月都补上，再LAG(…, 12)才能取到正确的去年值。
还有一个细节值得注意：环比除法的分母为0时的处理。补零后，上一周期为0是常见现象，这时增长率应该怎么显示？建议直接返回NULL或标记为“新增”，而不是用INFINITY去参与前端计算，否则图表会出现很夸张的线条。
4.2 累计值和移动平均补零后的注意事项
补零后做累计值，SUM(…) OVER (ORDER BY …) 的累加逻辑天然依赖于连续序列，所以补零的必要性更强。比如计算今年每天的累计销售额：
SELECT order_date, total_amount, SUM(total_amount) OVER (ORDER BY order_date) AS cumulative_amount FROM sales;要点在于累计值用的是窗口内的current row，如果某天补了0，累计值保持不变，这是正确的。如果你不补零，缺天的累计值就不会出现，前端做面积图时会断，后续天的累计值画出来还会在时间轴上错位。
移动平均也一样，7天移动平均AVG(total_amount) OVER (ORDER BY order_date ROWS BETWEEN 6 PRECEDING AND CURRENT ROW)，如果序列不连续，这个7天的窗口实际上横跨了7条记录但不一定等于7天，结果就会失真。补零后窗口才真正对应时间跨度。
我自己在金融行业做过一个资金流动性报表，每天余额要补零后算30天滚动均值，最初没有补零，直接窗口函数算，结果月末的曲线总比实际低一截，排查了半天才发现是缺日期导致窗口横跨了30个交易日但实际日历时间只有20多天。补零后曲线一下就平滑了。
5. 补零查询的性能问题与优化
很多同学说补零SQL能写出来，但一跑就慢得离谱。尤其是几百万、上千万行的订单表，加上递归CTE后，查询经常几十秒出不来。这里面的性能关键点其实没那么玄，主要就是驱动顺序和索引。
5.1 大表补零为什么慢
补零SQL慢主要有三个原因。
第一个原因是递归CTE本身产生了大量中间行。如果一个递归生成了10万天的序列，虽然看上去不多，但每次迭代都是一次派生表操作，有的数据库优化器会物化这个中间结果，占用临时表空间。我之前在MySQL 8.0里生成3年日期序列，没限制递归深度时，直接报了“内存临时表大小超限”。
第二个原因是LEFT JOIN的顺序问题。完整日期序列是驱动表，业务表是被驱动表。很多人建索引时只在业务表的时间列上建了普通索引，但LEFT JOIN需要从业务表反查大量匹配行，如果索引区分度不高，就会退化成每行都回表。
第三个原因是GROUP BY聚合时候选集太大。如果把补零的LEFT JOIN先做，再GROUP BY，中间结果集可能是业务表行数与日期序列行数的乘积爆炸，尤其是业务表中同一天有多行数据时。
5.2 先聚合再关联，顺序决定生死
一个非常实用的优化技巧：先对业务表做GROUP BY聚合，生成紧凑的“日期+汇总值”结果集，再与日期序列做LEFT JOIN。这样关联的数据量从订单表的行数降为业务日期数，性能提升非常明显。
WITH RECURSIVE date_seq AS (...), daily_sales AS ( SELECT order_date, SUM(amount) AS total_amount FROM orders WHERE order_date BETWEEN '2024-03-01' AND '2024-03-07' GROUP BY order_date ) SELECT ds.d AS order_date, COALESCE(ds2.total_amount, 0) AS total_amount FROM date_seq ds LEFT JOIN daily_sales ds2 ON ds2.order_date = ds.d ORDER BY ds.d;注意，这里WHERE条件一定要加，只统计你需要的时间范围，别把整表白查了。MySQL 8.0的优化器虽然会做条件下推，但能自己控制的范围就不要依赖优化器。
5.3 索引和递归深度限制
索引方面，业务表的order_date列建一个普通B-tree索引就够了。如果查询还带其他过滤条件（比如只看某个分类），那就要建联合索引，把分类字段放前面、日期放后面。
递归深度限制是个隐蔽的坑。MySQL 8.0默认cte_max_recursion_depth是1000，也就是说一次性递归生成1001天以上的序列就会报错：
SET SESSION cte_max_recursion_depth = 10000;SQL Server的递归上限默认是100层，超出会报“The statement terminated. The maximum recursion 100 has been exhausted”，要用OPTION (MAXRECURSION 0) 解除限制：
WITH date_seq AS (...) SELECT * FROM date_seq OPTION (MAXRECURSION 0);这个0表示无限，但生产环境建议不要设0，设一个足够大的具体值，比如3650，防止程序bug导致无限递归拖垮数据库。
PostgreSQL的递归不受显式层数限制，是通过work_mem等参数控制资源使用，但默认可以一直递归，遇到死循环时只能用statement_timeout兜底。
5.4 长周期补零的工程化解决方案
如果补零的周期很长，比如要生成5年的日历，每次都用递归CTE造，性能确实不太好。更工程化的做法是在数据仓库里建一张“日历维度表”，预先把未来10年每天一行都建好，字段包括日期、年、月、周、星期几、是否工作日、是否节假日。日常查询直接关联日历维度表，不需要每次递归生成序列，性能稳定且写法统一。
SELECT c.calendar_date, COALESCE(s.total_amount, 0) AS total_amount FROM dim_calendar c LEFT JOIN daily_sales s ON s.order_date = c.calendar_date WHERE c.calendar_date BETWEEN '2024-03-01' AND '2024-03-07' ORDER BY c.calendar_date;这套方案做数据仓库的都应该熟悉，相当于用空间换时间，一劳永逸。
6. 常见问题与踩坑实录
最后把这些年实际碰到的坑集中列一下，基本都是网上查不到、只有跑过才明白的细节。
6.1 日期类型与字符串比较的隐形坑
写关联条件时，最容易翻车的是日期类型和字符串日期比较。比如业务表里order_date是DATETIME类型，你生成的序列是DATE类型，MySQL里一般能隐式转换，但SQL Server里DATETIME和DATE比较会有cast转换开销。而且如果序列里是'2024-03-01 00:00:00'，业务表里是'2024-03-01 08:30:15'，两者根本不等，关联不上。所以关联之前一定要先明确类型和精度，要么统一DATE，要么统一截断到小时。
还有一个坑：前端传入的日期参数是字符串，直接拿来做关联，如果格式不一致，比如一个是'2024/03/01'，一个是'2024-03-01'，匹配全部失败，结果看似补零成功，其实是全表都补零了。排查这种问题很简单，关联前先用SELECT单独查一下序列和业务表里的日期格式，一眼就能看出来。
6.2 递归CTE的默认上限卡死报表
前面提到过MySQL默认1000层的限制，这里再补充一个实际生产案例。我遇到过按月统计需要生成60个月的序列，MySQL直接报错，当时排查了半天才发现是cte_max_recursion_depth的问题。解决办法是在会话级别调大：
SET SESSION cte_max_recursion_depth = 100000;但要注意，这个参数设置得太大，加上糟糕的递归逻辑，可能把数据库内存打爆。建议设置一个业务永远用不到的合理上限，比如100000，同时SQL里尽量缩小递归范围。
6.3 补零后SUM还是NULL的问题
COALESCE到底包在哪里，很多新手搞不清。前面讲过GROUP BY后，SUM聚合结果在无匹配行时是NULL，必须用COALESCE(SUM(o.amount), 0)。但需要注意，如果是多表关联之后做的SUM，有时会忽略补零行在驱动表一侧的NULL问题。
举个例子，如果业务表里某天确实有一行记录，但amount字段本身是NULL，那么SUM的结果会是NULL，但COUNT(o.id)会是1。这时报表上会显示“有记录但金额为空”，看起来像数据问题。处理方式是COALESCE(o.amount, 0)先做字段级空值处理，再SUM：
SELECT ds.d AS order_date, COALESCE(SUM(COALESCE(o.amount, 0)), 0) AS total_amount FROM date_seq ds LEFT JOIN orders o ON o.order_date = ds.d GROUP BY ds.d;6.4 关联条件写在WHERE里会让LEFT JOIN失效
这是一个经典错误：补零序列和业务表LEFT JOIN之后，如果想过滤某天的数据，把过滤条件写在WHERE里，比如WHERE o.order_date IS NOT NULL或者WHERE o.amount > 0，会导致LEFT JOIN退化成INNER JOIN，补零效果消失。因为WHERE是在JOIN之后才执行过滤的，NULL行会被直接过滤掉。
正确做法是：过滤条件全部放在JOIN的ON子句里：
LEFT JOIN orders o ON o.order_date = ds.d AND o.status = 'paid'这样即使该日期没有已支付订单，日期行依然保留在结果集里，值补0。这个细节我至少见过三次有人踩进去，改起来又很快，但排查时特别迷惑。
6.5 补零后排序不稳定
补零后结果集变大了，如果没有明确的ORDER BY，数据库返回顺序可能不稳定。尤其在分页查询时，同一页数据可能每次刷新都不一样。补零SQL一定要在最后加上ORDER BY日期或其他业务排序键，而且排序键最好唯一。如果需要固定顺序，可以再加一个辅助排序列，比如星期几，让报表前端展示稳定。
另外，在处理跨时区的补零场景时，比如报表按“北京时间”的日期分组，而数据库存储的是UTC时间，直接按存储日期分组会有时差。需要在生成序列和关联时统一使用CONVERT_TZ之类的时区转换函数，或者在建表时就约定好存储时区。这类问题在日志分析系统里特别常见。
7. 一个完整案例：从原始需求到最终SQL
把前面所有知识串起来，我用一个完整的需求演示一遍，也算是对整篇文章的总结。假设有一个销售系统，要出2024年3月的每日销售报表，展示日期、订单数、销售额、环比销售额，前端要求缺数据的日期也必须显示。
先说步骤：第一步，生成整月日期序列；第二步，从销售表按天聚合订单数和销售额；第三步，把序列和聚合结果LEFT JOIN；第四步，补零；第五步，用窗口函数算环比。
最终SQL（以MySQL 8.0为例）：
WITH RECURSIVE date_seq AS ( SELECT DATE('2024-03-01') AS d UNION ALL SELECT d + INTERVAL 1 DAY FROM date_seq WHERE d < DATE('2024-03-31') ), daily_sales AS ( SELECT order_date, COUNT(*) AS order_cnt, COALESCE(SUM(amount), 0) AS amount FROM orders WHERE order_date BETWEEN '2024-03-01' AND '2024-03-31' AND status = 'paid' GROUP BY order_date ) SELECT ds.d AS report_date, COALESCE(s.order_cnt, 0) AS order_cnt, COALESCE(s.amount, 0) AS amount, LAG(COALESCE(s.amount, 0)) OVER (ORDER BY ds.d) AS prev_amount, CASE WHEN LAG(COALESCE(s.amount, 0)) OVER (ORDER BY ds.d) = 0 THEN NULL ELSE COALESCE(s.amount, 0) - LAG(COALESCE(s.amount, 0)) OVER (ORDER BY ds.d) END AS diff_amount FROM date_seq ds LEFT JOIN daily_sales s ON s.order_date = ds.d ORDER BY ds.d;执行结果就是完整的31行，每一天都有值，没卖出去的那几天订单数和销售额都是0，环比显示为0或NULL，前端直接拿这个结果集画图不需要任何额外处理。
这个案例看起来简单，但每一行都有讲究：递归默认上限、COUNT和SUM的COALESCE位置、LEFT JOIN后不能在WHERE里过滤、窗口函数必须基于补零后的完整序列。把这些搞明白，补零这个需求对你来说就没有任何秘密了。
在实际操作中，我一般建议报表开发把“日历维度表”作为默认方案，把递归CTE作为临时快速方案。毕竟业务的生命周期越来越长，每次重写递归序列总不是长久之计。补零的核心就一句话：先造完整的序列，再关联聚合后的数据，最后COALESCE补0。记牢这句话，任何复杂的补零需求都能拆解得清清楚楚。
