MySQL 5.7 中应使用整数计数器（DECLARE i INT DEFAULT 0）配合 DATE_ADD(start_date, INTERVAL i DAY) 生成连续日期，start_date 必须显式转为 DATE 类型，且需添加 IF i > 1000 THEN LEAVE loop_label; END IF; 防无限循环。
MySQL 5.7 怎么用 WHILE 循环安全生成连续日期序列
MySQL 5.7 不支持 WITH RECURSIVE，也没 GENERATE_SERIES，唯一可靠方式是用 WHILE + 变量构造。但直接操作日期变量极易卡死在 NULL 上——比如写 @d := DATE_SUB(@d, INTERVAL 1 DAY)，一旦 @d 变成 NULL，后续所有 DATE_SUB(NULL, ...) 都返回 NULL，循环就再也出不来。
正确做法是用整数计数器控制步进：
- 声明
DECLARE i INT DEFAULT 0和DECLARE start_date DATE（必须用DATE()或STR_TO_DATE()显式转换，别传字符串） - 循环体内用
DATE_ADD(start_date, INTERVAL i DAY)算当天日期，不碰@date变量 - 加硬性退出条件：
IF i > 1000 THEN LEAVE loop_label; END IF;，防止因起止日期算错导致无限循环 - 每次插入前检查
dt是否在目标范围内，别只靠循环次数——i超了但日期还没到终点时，仍可能漏数据
SQL Server 怎么用 CTE 批量生成日期序列不查表
别写 WHILE 循环逐天 INSERT，也别在循环里反复 SELECT FROM Holidays——跨度大时性能直接崩。CTE + 数字表才是批量生成的正解。
没现成数字表？可用 master..spt_values 临时顶替（仅限开发），但生产环境必须建真实 Numbers 表：
-
CREATE TABLE dbo.Numbers (n INT PRIMARY KEY);插入 0–10000 的连续整数 - CTE 写法：
WITH dates AS (SELECT DATEADD(DAY, n.n, @start_date) AS dt FROM dbo.Numbers n WHERE n.n BETWEEN 0 AND DATEDIFF(DAY, @start_date, @end_date)) - WHERE 条件必须用
BETWEEN或，别用 <code>n.n ——SQL Server 对表达式索引不友好，可能全表扫描 - 如果用
master..spt_values，要加WHERE type = 'P'过滤，否则会混入非数字行
LEFT JOIN 补全日期时为什么结果还是缺天
生成好 tmp_dates 表后 LEFT JOIN 业务表，结果却仍有日期缺失，大概率是 JOIN 条件或索引问题。
常见陷阱：
-
LEFT JOIN orders ON DATE(orders.order_time) = tmp_dates.dt—— 这会让order_time上的索引失效；改成orders.order_time >= tmp_dates.dt AND orders.order_time ，并确保 <code>order_time有索引 -
tmp_dates.dt字段没索引：即使只是临时表，也得CREATE INDEX idx_dt ON tmp_dates(dt)，否则 JOIN 时优化器可能放弃使用它 - 日期类型不一致：
tmp_dates.dt是DATE，但orders.order_time是DATETIME且带时分秒——没问题；但如果dt存的是字符串，隐式转换会导致索引失效甚至匹配错误 - JOIN 后没
GROUP BY tmp_dates.dt就直接COUNT(*)，聚合逻辑错位，看起来像缺数据
PostgreSQL 和 MySQL 8.0 的生成方式能互相移植吗
不能直接抄。函数名、语法、日期逻辑全不同，硬搬会报错或结果错乱。
关键差异点：
- PostgreSQL 用
generate_series('2026-01-01'::date, '2026-12-31'::date, '1 day'::interval)，返回的是date类型；MySQL 8.0 的WITH RECURSIVE必须显式CAST(... AS DATE)，否则默认是DATETIME - 周末判断：PostgreSQL
EXTRACT(ISODOW FROM dt)返回 1–7（周一=1），周末是 0 和 6；MySQL 8.0 用WEEKDAY(dt)（周一=0）或DAYOFWEEK(dt)（周日=1），数值含义完全相反 - MySQL 8.0 的递归 CTE 默认最大深度 1000，跨 3 年可能触发
ERROR 3636，得加SET SESSION cte_max_recursion_depth = 10000; - PostgreSQL 的
generate_series性能远高于 MySQL 的 CTE，尤其在上万行规模时，别拿 MySQL 的写法去压测 PG
最易被忽略的是时区和 DATE 函数行为：所有涉及日期计算的地方，都得确认当前会话的 TZ 和 sql_mode（MySQL）或 timezone（PG），否则同一条语句在不同环境结果可能差一天。
