正确分组需用CONCAT(YEAR(create_time), '-Q', QUARTER(create_time))生成唯一季度键，字符串日期须先STR_TO_DATE()转换，时区不一致时用CONVERT_TZ()校正，WHERE条件应使用闭区间避免漏数据。
MySQL中用QUARTER()和YEAR()组合实现自然季度分组
直接用 QUARTER(date_col) 会丢掉年份信息，导致Q1跨年合并（比如2023-01和2024-01被算作同一组）。必须和 YEAR() 联合使用才能保证每个季度唯一标识。
正确写法是：CONCAT(YEAR(create_time), '-Q', QUARTER(create_time))，生成类似 '2023-Q1' 这样的分组键。别用 DATE_FORMAT(create_time, '%Y-Q%q') —— MySQL 5.7 不支持 %q，8.0+虽支持但可读性差且部分客户端解析异常。
- 如果字段是字符串类型（如
'2023-03-15'），先用STR_TO_DATE()转成日期再计算，否则QUARTER()返回NULL - 注意时区：若服务器时区和业务时区不一致（比如服务器设为 UTC，而业务按东八区统计），需在计算前用
CONVERT_TZ()校正，否则跨零点的数据可能进错季度
避免WHERE条件误伤季度边界
常见错误是写 WHERE create_time >= '2023-01-01' 来取2023全年数据——这会漏掉2023-Q1中 create_time 是 '2023-01-01 00:00:00' 之前（毫秒级）的记录，尤其当字段含微秒或时区偏移时。
更安全的做法是用季度范围闭区间：WHERE create_time >= '2023-01-01' AND create_time 。这样既覆盖整个自然年，又不会因时间精度问题漏数据。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 动态生成季度起止时间可用
MAKEDATE(YEAR(NOW()), 1) + INTERVAL (QUARTER(NOW())-1) QUARTER算本季度初，但生产环境建议预计算或用应用层传参，避免每次查询都执行复杂表达式 - 对高频查询，给
create_time建INDEX；若常按季度+其他字段联合过滤，考虑建复合索引，例如INDEX idx_qtr_status (create_time, status)
处理空值与非法日期导致的NULL分组
QUARTER(NULL) 和 QUARTER('0000-00-00') 都返回 NULL，这些记录会被聚到同一个 NULL 组里，容易掩盖脏数据问题。
上线前务必检查：SELECT COUNT(*) FROM t WHERE create_time IS NULL OR create_time = '0000-00-00' OR create_time = '1000-01-01';。有结果就说明存在无效时间，不能直接分组统计。
- 清洗方案：用
CASE WHEN过滤或映射到默认季度（如ELSE 'UNKNOWN-Q0'），但需在业务侧明确该口径是否可接受 - 建表时加约束更治本：
create_time DATE NOT NULL DEFAULT '1970-01-01'，配合应用层校验，比查后补救成本低得多
MySQL 5.7 vs 8.0 的DATE_SUB季度推算差异
想查“上一季度”数据时，有人写 DATE_SUB(NOW(), INTERVAL 1 QUARTER)。这在 8.0+ 没问题，但在 5.7 中，INTERVAL 1 QUARTER 可能因月份天数不同（如从3月31日减一季度得2月31日）触发隐式截断，返回 '2023-02-00' 这类非法日期，导致后续 QUARTER() 计算失败。
兼容写法是手动算季度初：MAKEDATE(YEAR(DATE_SUB(NOW(), INTERVAL 3 MONTH)), 1) + INTERVAL (QUARTER(DATE_SUB(NOW(), INTERVAL 3 MONTH))-1) QUARTER，虽然长，但 5.7/8.0 都稳。
- 测试时一定要用真实季度末日期（如
'2023-03-31'、'2023-06-30'）验证，别只用'2023-01-15'这类中间日 - 如果项目已用 8.0+，优先用
DATE_QUARTER_START()（8.0.22+）这类专用函数，语义清晰且无歧义
