核心思路是按user_id分组，对purchase_time字段用MIN()和MAX()分别提取首次与末次购买时间，需确保字段为DATETIME/TIMESTAMP类型或格式统一的字符串，配合GROUP BY使用，并建议建立(user_id, purchase_time)复合索引以提升性能。
用 MIN() 和 MAX() 提取首末购买时间
核心思路是按 user_id 分组，对 purchase_time（假设字段名）分别取最小值和最大值。注意：必须确保该字段是 DATETIME 或 TIMESTAMP 类型，否则 MIN()/MAX() 可能按字符串比较，导致结果错误。
常见错误是直接在未分组的表上用 MIN(purchase_time)，结果会返回全表最早时间，而非每个用户各自的首次时间。
- 正确写法：
SELECT user_id, MIN(purchase_time) AS first_buy, MAX(purchase_time) AS last_buy FROM orders GROUP BY user_id - 如果时间字段是字符串（如
'2023-01-01'），且格式统一为YYYY-MM-DD，MIN/MAX仍可工作；但含时分秒或格式不一致（如'01/01/2023'）时，必须先用STR_TO_DATE()或TO_TIMESTAMP()转换 - PostgreSQL 用户需注意：
MIN()/MAX()对timestamp类型安全；若字段为text，必须显式::timestamp强转
计算间隔天数（跨数据库写法）
间隔天数不是简单减法，不同数据库日期相减返回类型不同：MySQL 返回天数（DATE 相减得整数），PostgreSQL 返回 interval，SQL Server 需用 DATEDIFF()。
最稳妥的跨库写法是用标准函数 EXTRACT(EPOCH FROM ...)（PostgreSQL）或 TIMESTAMPDIFF()（MySQL），但更通用的做法是统一转为日期再相减。
- MySQL：
TIMESTAMPDIFF(DAY, MIN(purchase_time), MAX(purchase_time)) - PostgreSQL：
(MAX(purchase_time)::date - MIN(purchase_time)::date)（返回整数天） - SQLite：
julianday(MAX(purchase_time)) - julianday(MIN(purchase_time)) - 避免直接写
MAX(...) - MIN(...)—— 在 PostgreSQL 中结果是interval类型，不能直接参与数值运算
处理单次购买用户（避免 NULL 或负值）
当某用户只买一次，first_buy 和 last_buy 相等，间隔为 0 天。但更常见问题是：数据里存在异常时间（如 '0000-00-00' 或 NULL），会导致 MIN/MAX 返回 NULL，整个间隔字段变 NULL。
- 务必加过滤：
WHERE purchase_time IS NOT NULL AND purchase_time != '0000-00-00'（MySQL）或purchase_time > '1970-01-01' - 用
CASE WHEN COUNT(*) = 1 THEN 0 ELSE ... END显式处理单次购买，比依赖日期相减更可控 - 如果业务要求“至少两次购买才计算”，则在外层加
HAVING COUNT(*) > 1
性能关键：索引必须覆盖 user_id + purchase_time
这个查询本质是分组聚合，没有合适索引时会触发全表扫描+临时文件排序，尤其在百万级订单表上可能秒变十几秒。
- 最优索引：
CREATE INDEX idx_user_purchase ON orders (user_id, purchase_time) - 不要只建
(user_id)单列索引——优化器无法跳过排序步骤 - 验证是否走索引：执行
EXPLAIN，看key列是否显示该索引，且Extra不含Using filesort或Using temporary - 如果表有分区（如按月分区），确保
purchase_time是分区键的一部分，否则跨分区扫描代价极高
实际跑起来才发现，purchase_time 字段如果有大量 NULL 或非法值，MIN/MAX 会静默忽略它们——这看起来像“功能正常”，但可能导致间隔被低估。上线前最好抽样检查几个 user_id 的原始记录。
