MySQL 递归 CTE 生成日期序列时为什么列类型会截断

用 MySQL 递归 CTE 生成日期序列时，如果日期列在递归后半段出现截断、严格模式报错，先不要改 cte_max_recursion_depth。更常见的根因是：递归 CTE 的列类型只由非递归部分，也就是第一个 SELECT 决定，递归部分生成什么类型并不会反过来扩大它。

官方资料：https://dev.mysql.com/doc/refman/8.4/en/with.html

先修正非递归锚点的类型，再检查结束条件。递归部分即使写出了更宽的值，也不能替换已经确定的 CTE 列定义。

为什么递归日期列会在后半段出问题

MySQL 把递归 CTE 分成锚点和递归成员：锚点产生第一行，递归成员从上一轮结果继续生成数据。官方规则是，结果列类型只从锚点推断，递归成员在类型推断阶段会被忽略。

这条规则在日期序列里容易被忽略，因为真正变宽的可能不是日期本身，而是同时携带的标签列、路径列或格式化文本。非严格模式可能悄悄截短，严格模式则常见 ERROR 1406 Data too long。把问题归因于“递归次数太多”会走错方向。

可以把判断点压缩成一张表：

用显式日期类型固定锚点

生成日期序列时，最稳妥的写法是让锚点直接成为 DATE，递归成员只负责加一天：

-- 锚点先固定为 DATE，递归列不会依赖字符串常量的隐式类型
WITH RECURSIVE date_series (day_value) AS (
    SELECT CAST('2026-09-01' AS DATE)
    UNION ALL
    -- 递归成员只推进日期，并在结束日期前继续生成
    SELECT DATE_ADD(day_value, INTERVAL 1 DAY)
    FROM date_series
    WHERE day_value 

这里的关键不在于给递归成员再包一层 CAST，而在于锚点已经明确声明了列的真实语义。结束日期也显式转成 DATE，可以避免比较时混入时间部分或隐式转换。

如果还要生成“周一”“工作日”之类的展示字段，先保持日期列为 DATE，再在外层查询计算。这样业务表用 DATE 关联时，索引和条件更容易保持清晰。

把日期、格式化文本和结束条件分开

不要在递归列里直接把日期变成展示字符串。下面的写法把三件事拆开：CTE 保存日期，外层生成标签，递归条件独立表达边界。

-- CTE 保存可参与日期比较和关联的 DATE 列
WITH RECURSIVE date_series (day_value) AS (
    SELECT CAST('2026-09-01' AS DATE)
    UNION ALL
    SELECT day_value + INTERVAL 1 DAY
    FROM date_series
    -- 明确包含 09-07，避免结束条件多生成或少生成一天
    WHERE day_value 

DATE_FORMAT() 在外层只是显示层；LEFT JOIN 让没有销售记录的日期仍然保留。若查询需要携带递归路径或拼接标签，则要在锚点为对应字符串显式指定足够宽度，例如 CAST('' AS CHAR(255))，否则同样会触发截断。

上线前检查哪些边界

先确认起止日期的包含关系，再检查日期跨度是否可能超过默认递归深度。MySQL 文档说明，cte_max_recursion_depth 用于限制递归层数；它解决的是“递归太深”，不是“列类型太窄”。

• 需要包含结束日期时，用 day_value 生成下一行，并确认最后一行能够等于结束日期。
• 起止范围来自参数时，在锚点和边界比较处统一成 DATE，避免一个是 DATETIME、另一个是字符串。
• 跨度很大时评估日历表或预生成日期维度，不要只把递归深度调得很高。
• 严格模式下出现截断错误，优先回看非递归 SELECT 的类型，而不是先关闭严格模式。

常见问题

为什么递归 SELECT 里 CAST 成 DATE 仍然没有解决问题？

因为类型推断看的是非递归 SELECT。应先修改锚点；递归成员的 CAST 只能表达当前计算，不会重新定义 CTE 列。

日期列一定要用 DATE，不能用 DATETIME 吗？

不是。是否使用 DATETIME 取决于业务是否需要时间部分，但锚点、边界参数和关联字段最好统一，避免隐式转换改变比较结果。

把严格 SQL 模式关闭能绕过截断吗？

可能只让错误变成静默截断，数据仍然不完整。生产查询应扩大锚点类型或拆分展示字段，保留严格模式帮助尽早暴露问题。