应先用WHERE按时间戳过滤再GROUP BY，避免HAVING配合MAX导致全表扫描和逻辑错误；created_at需加索引，注意时区统一与边界条件使用>=和
WHERE子句里直接用时间戳字段过滤，别先GROUP BY再筛
很多人写成 GROUP BY user_id HAVING MAX(created_at) BETWEEN '2024-01-01' AND '2024-01-31'，这会导致全表扫描后再聚合，性能极差，且逻辑错误——它找的是“最后活跃在该区间”的用户，不是“期间内有任意一次活跃”的用户。
正确做法是：先用 WHERE 把时间范围卡死，再分组统计。数据库能走索引，结果也符合业务定义（只要有一次落在区间内就算活跃）。
-
created_at字段必须有索引，否则WHERE过滤仍慢 - 注意时区：如果
created_at是TIMESTAMP类型，MySQL 默认按系统时区解析字符串；PostgreSQL 更严格，建议显式用AT TIME ZONE或统一存 UTC - 边界包含问题：用
>=和比BETWEEN更安全，避免因毫秒/微秒截断导致漏掉末尾记录
统计“活跃分组”常用模式：COUNT(DISTINCT ...) vs GROUP BY + COUNT(*)
要看你定义的“活跃分组”是什么：
- 如果是“有多少个不同用户在该时间段内发过帖”，用
COUNT(DISTINCT user_id)，简单直接 - 如果是“每个用户发了多少条”，就必须
GROUP BY user_id，再COUNT(*)，不能省 - PostgreSQL 和 MySQL 8.0+ 支持
GROUP BY后用窗口函数补总数，但多数场景没必要，先过滤再分组更清晰
示例（统计每日每个渠道的活跃用户数）：
WHERE created_at BETWEEN '2024-01-01' AND '2024-01-31'
-
created_at是DATETIME或TIMESTAMP，而传入的字符串没带时分秒，默认变成'2024-01-01 00:00:00'，但实际数据是'2024-01-01 14:23:05'—— 这本身没问题；真正坑是下一条 -
created_at实际是字符串类型（VARCHAR），比如存成'2024/01/01 14:23'，此时BETWEEN做字典序比较，'2024/02/01' 成立，结果错乱 - MySQL 中
STR_TO_DATE()在WHERE里用会导致索引失效，别这么干
查证方式：运行 DESCRIBE table_name 或 SHOW COLUMNS LIKE 'created_at'，确认类型是 TIMESTAMP/DATETIME，不是 TEXT 或 VARCHAR。
跨天或跨月统计时，别依赖函数包裹时间字段做索引
像 WHERE DATE(created_at) = '2024-01-01' 或 WHERE YEAR(created_at)=2024，会让数据库无法使用 created_at 上的索引，强制全表扫描。
替代写法一律改用范围比较：
- 某天全部数据：
WHERE created_at >= '2024-01-01' AND created_at - 某月全部数据：
WHERE created_at >= '2024-01-01' AND created_at - 需要按自然日分组？
GROUP BY DATE(created_at)可以留到 SELECT 和 GROUP BY 阶段，WHERE 里仍用原生时间范围
这个细节在百万级以上表上，响应时间可能从 200ms 拉到 8s，而且容易被忽略——因为小数据量时看不出差别。
