group by + having 可识别长期未登录用户，需结合时间字段聚合判断零/低频活跃；须避免where函数运算、时区偏差及null遗漏，并用not exists精准查“从未登录”用户。
GROUP BY + HAVING 找出长期未登录的用户
直接用 GROUP BY 本身不能识别僵尸用户，但配合 HAVING 和时间字段聚合，能高效暴露“零活跃”或“低频活跃”的用户群。关键不是看单条记录，而是看分组后的行为缺失——比如某用户在指定周期内登录次数为 0 或极少。
常见错误是只查 last_login IS NULL，这漏掉大量「曾经登录过、但最近彻底停用」的用户；也别用 WHERE last_login ，它无法区分「刚注册还没登录」和「登录后弃用」两类人。
- 先按用户分组，统计每个用户在目标周期内的登录次数：
COUNT(*)或COUNT(login_id) - 用
HAVING COUNT(*) = 0筛出完全没登录过的用户（需确保登录日志表 LEFT JOIN 用户表） - 若要查「近30天登录≤1次」的准僵尸用户，写成
HAVING COUNT(*) - 注意：
login_time字段必须有索引，否则WHERE login_time >= ...过滤会拖慢聚合速度
MySQL 中用 TO_DAYS() 做日期差计算的陷阱
JumpServer 等系统常用 TO_DAYS(NOW()) - TO_DAYS(last_login) >= 30 判定僵尸用户，但这个写法在跨月/跨年时可能出错——TO_DAYS() 返回的是自公元0年起的天数，看似安全，实则隐含时区风险：如果 last_login 存的是 UTC 时间，而 NOW() 返回本地时区时间，差值就可能少算或多算一天。
- 更稳妥的做法是统一转为日期再比较：
DATE(NOW()) - INTERVAL 30 DAY > DATE(last_login) - 若
last_login允许为NULL，必须显式处理：last_login IS NULL OR DATE(NOW()) - INTERVAL 30 DAY > DATE(last_login) - 避免在
WHERE中对last_login做函数运算（如DATE(last_login)），否则无法走索引
Oracle 里不能只靠 DBA_USERS.ACCOUNT_STATUS 查僵尸用户
DBA_USERS.ACCOUNT_STATUS 只反映账号锁定/过期状态，不反映实际使用活跃度。一个 OPEN 状态的账号，可能三年没登过一次——这才是业务意义上的“僵尸用户”。
真正要查的是「账号状态正常但连接长期闲置」的组合：
- 关联
v$session，筛选status = 'INACTIVE'且last_call_et > 86400（24小时） - 排除
type = 'BACKGROUND'和username IS NULL的伪会话 - 重点看
logon_time是否远早于当前时间，且期间无任何sql_id记录 - 如果同一
username下有多个长时间INACTIVE会话，基本可判定是应用端连接泄漏，不是用户主动弃用
NOT EXISTS 比 LEFT JOIN 更适合定义“从未登录”的僵尸用户
判断「注册了但从没登录过」这类僵尸用户，本质是集合补集问题。用 LEFT JOIN login_log ON users.id = login_log.user_id WHERE login_log.user_id IS NULL 看似合理，但一旦 login_log 表存在重复记录或脏数据（比如测试脚本刷出的无效日志），结果就会失真。
- 正确写法是：
SELECT * FROM users u WHERE NOT EXISTS (SELECT 1 FROM login_log l WHERE l.user_id = u.id AND l.login_time >= DATE_SUB(NOW(), INTERVAL 90 DAY)) -
NOT EXISTS语义明确：对每个用户，检查是否存在匹配的登录记录；不依赖连接结果是否为空行 - 把时间条件（如近90天）放在子查询里，而不是外层
WHERE，避免误筛掉历史活跃但近期沉默的用户 - 若
login_log.user_id缺少索引，NOT EXISTS性能会断崖下跌——务必确认该字段已建索引
GROUP BY 本身不带业务语义，“僵尸用户”永远是业务定义+数据行为+时间窗口共同决定的。最容易被忽略的是：同一套 SQL 在 MySQL 和 Oracle 里，因 NULL 处理、日期函数、执行计划差异，结果可能完全不同。别迷信语法，先验证数据分布。
