week函数在不同数据库中定义不一致，需按iso标准统一处理：mysql用week(date,1)或yearweek(date,1)，postgresql用extract(isoweek from date)，sql server用datepart(iso_week,date)配合set datefirst 1；统计新增用户须先取每个用户的最小时间再归周；跨年周需组合年份与周数作为分组键；避免直接对week()函数结果索引，应改用日期范围查询或生成列索引。
WEEK函数在不同数据库里根本不是一回事
MySQL 的 WEEK()、PostgreSQL 的 EXTRACT(WEEK FROM ...)、SQL Server 的 DATEPART(week, ...) 返回的周数定义完全不同——有的从周日算起，有的按 ISO 标准（周一为每周第一天，且第 1 周必须包含当年至少 4 天），还有的把 1 月 1 日所在周硬算作第 1 周。直接套用 WEEK() 得到的“第 5 周”在不同库甚至不同年份可能指向完全不同的日期范围。
实操建议：
- MySQL 用户优先用
WEEK(date_col, 1)（第二个参数1表示周一为每周开始，ISO 模式），避免默认的0（周日开始，非 ISO） - PostgreSQL 必须用
EXTRACT(ISOWEEK FROM date_col)，而不是EXTRACT(WEEK FROM ...)——后者依赖datestyle设置，极不稳定 - SQL Server 要搭配
SET DATEFIRST 1（设周一为每周第一天），再用DATEPART(ISO_WEEK, date_col)，否则DATEPART(week, ...)会按服务器默认设置走
统计“每周新增用户”不能只靠WEEK函数
新增用户 = 首次出现的用户 ID。如果只按注册日期的周数分组，会把同一用户在多周的登录行为误算成多周新增。必须先识别每个用户的最早行为时间，再按该时间归周。
实操建议：
- 先用窗口函数或子查询求出每个
user_id的最小时间（如MIN(created_at)），生成“首活时间”临时表 - 再对这个首活时间字段应用周计算函数，例如 MySQL：
WEEK(MIN(created_at), 1) - 别在原始表上直接
GROUP BY WEEK(created_at)—— 这统计的是“每周注册量”，不是“每周首次访问的新用户”
跨年周容易错算成两行
比如 2024-12-30（周一）属于 ISO 第 53 周，但 MySQL 默认 WEEK('2024-12-30') 可能返回 52 或 1，取决于模式参数和年份边界处理逻辑。结果就是：同一年的跨年周数据被拆到两个年份桶里，或者不同年份的同一 ISO 周被合并。
实操建议：
- 必须同时提取年份和周数，并组合使用：MySQL 用
YEARWEEK(created_at, 1)（返回类似202453的整数），PostgreSQL 用EXTRACT(ISOYEAR FROM ...) * 100 + EXTRACT(ISOWEEK FROM ...) - 避免单独用
WEEK()或EXTRACT(WEEK FROM ...)作为分组键 - 前端展示时再把
202453解析成 “2024-W53”，别在 SQL 里拼字符串——影响索引和排序
性能陷阱：WEEK函数会让索引失效
在 WHERE WEEK(created_at) = 5 或 GROUP BY WEEK(created_at) 中，数据库无法使用 created_at 字段上的普通 B-tree 索引，因为函数改变了原始值的有序性。
实操建议：
- 改写为范围查询：想查第 5 周（ISO），就计算出这一周的起止时间（如
'2024-01-29'到'2024-02-04'），然后用created_at BETWEEN '2024-01-29' AND '2024-02-04' - 建生成列索引（MySQL 5.7+ / PostgreSQL 12+）：添加一个
iso_yearweek计算列并加索引，例如ALTER TABLE users ADD COLUMN iso_yw INT AS (YEARWEEK(created_at, 1)) STORED - 时间范围大时，优先用日期区间过滤，再做周聚合，而不是先全表计算 WEEK 再筛选
真正麻烦的不是怎么写 WEEK，而是怎么让“新增”定义清晰、跨年周对齐、查询不慢——这三个点没对齐，结果就不可信。
