用MIN()和MAX()配合GROUP BY计算单用户时间差需按数据库选函数：MySQL用TIMESTAMPDIFF，PostgreSQL直接减得interval，SQLite用julianday换算；须WHERE过滤有效登录记录；单次登录时间差为0合理，可加COUNT(*)辅助判断；应建(user_id, status, login_time)复合索引提升性能。
用 MIN() 和 MAX() 配合 GROUP BY 计算单用户时间差
直接对每个用户取 MIN(login_time) 和 MAX(login_time)，再相减即可。注意时间类型相减结果因数据库而异：MySQL 返回秒数（需 TIMESTAMPDIFF 控制单位），PostgreSQL 返回 interval，SQLite 需用 julianday() 转换。
常见错误是用 login_time - login_time 直接相减，这在 PostgreSQL 里能跑但语义模糊，在 MySQL 里可能得到意外整数（如 2023-01-01 10:00:00 - 2023-01-01 09:00:00 得到 10000，不是小时）。
- MySQL 推荐写法：
TIMESTAMPDIFF(SECOND, MIN(login_time), MAX(login_time))（单位可选MINUTE/HOUR/DAY） - PostgreSQL 写法：
MAX(login_time) - MIN(login_time)，结果是interval类型，如1 day 02:30:45 - SQLite 写法：
(julianday(MAX(login_time)) - julianday(MIN(login_time))) * 86400，得秒数
WHERE 条件漏加导致首次/末次错乱
如果表里有测试账号、机器人日志或异常状态（如 status = 'failed'），MIN()/MAX() 会把它们一起算进去，导致时间差严重失真。必须显式过滤有效登录记录。
- 确认业务中“登录成功”的标识字段，常见有：
status = 'success'、is_valid = 1、http_status = 200 - 不要只靠时间字段判断，比如
login_time IS NOT NULL不足以排除脏数据 - 示例（MySQL）：
SELECT user_id, TIMESTAMPDIFF(HOUR, MIN(login_time), MAX(login_time)) AS hour_diff FROM login_logs WHERE status = 'success' GROUP BY user_id
用户只登录一次时时间差为 0 的合理性
当某用户仅有一条有效登录记录，MIN() 和 MAX() 结果相同，时间差自然为 0。这不一定是 bug，而是符合定义的合理结果——“首次即末次”。但业务上可能需要区分“单次登录”和“数据缺失”。
- 加一列计数辅助判断：
COUNT(*) AS login_count，后续可筛出login_count = 1的用户单独分析 - 若想排除单次用户，加
HAVING COUNT(*) > 1，但注意这会让单次用户完全不出现在结果里 - 某些场景下更合适用
NULL表示无时间差，可用CASE WHEN COUNT(*) = 1 THEN NULL ELSE ... END
索引没建对会让查询变慢十倍以上
这个查询本质是分组聚合，性能瓶颈常在 GROUP BY user_id 和时间范围扫描。没索引时可能全表扫描+临时文件排序。
- 最有效索引：
CREATE INDEX idx_user_status_time ON login_logs (user_id, status, login_time)—— 把分组字段放最左，状态过滤次之，时间字段收尾 - 如果
status区分度低（如 95% 是 'success'），可去掉它，用(user_id, login_time)更紧凑 - 别只建
(login_time)单列索引，对GROUP BY user_id几乎无加速作用
实际执行前务必用 EXPLAIN 看是否走了索引，特别是当用户量过万、日志表超千万行时，没索引的 GROUP BY 很容易卡住连接。
