MySQL原生无last_login字段，需启用performance_schema.accounts并查LAST_SEEN；云数据库须通过控制台/API查审计日志；删账号前须验证活跃连接、代理关系及DEFINER依赖。
MySQL 原生不记录 last_login，所谓“长期未登录”只能靠外部可观测数据反推——要么启用 performance_schema.accounts（需手动开启），要么解析审计日志或通用日志；直接查 mysql.user 里的 password_last_changed 或空字段，99% 会误删。
怎么查 performance_schema.accounts 表里的真实登录时间
这张表的 LAST_SEEN 字段是唯一接近“最后成功认证时间”的原生字段，但它默认不采集，必须显式启用消费者：
- 先确认是否启用：
SELECT VARIABLE_VALUE FROM performance_schema.setup_consumers WHERE NAME = 'accounts';，返回NO就得执行UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME = 'accounts'; - 查 90 天内没连过的非系统账号：
SELECT USER, HOST FROM performance_schema.accounts WHERE USER NOT IN ('mysql.session', 'mysql.sys', 'root') AND LAST_SEEN - 注意：新创建但从未登录的账号根本不会出现在这张表里——它没被“认证过”，
LAST_SEEN是 NULL，得靠其他方式补漏
没开 accounts 消费者时，用 general_log 临时补位的实操要点
生产环境慎用，但测试/预发可快速落地。关键不是“开日志”，而是控制输出方式和清理节奏：
kashen-mysql DDLtoExcel
下载
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
- 别写文件，改用表存储：
SET GLOBAL general_log = ON; SET GLOBAL log_output = 'table';，日志进mysql.general_log，方便 SQL 查询 - 提取用户名要拆
user_host：SELECT DISTINCT SUBSTRING_INDEX(user_host, '@', 1) AS user FROM mysql.general_log WHERE command_type = 'Connect' AND event_time > DATE_SUB(NOW(), INTERVAL 90 DAY); - 该表无索引，数据量大时查询慢；定期清空：
TRUNCATE TABLE mysql.general_log;，别用DELETE，避免锁表 - 记得关掉：
SET GLOBAL general_log = OFF;，否则磁盘和性能双崩
云数据库（如腾讯云、阿里云）怎么拿到登录行为
你没法 ssh 进去读 /var/lib/mysql/audit.log，所有日志都得走控制台或 API，且有硬限制：
- 审计日志保留期通常为 30–180 天，先确认实际覆盖范围：
head -n 1 audit.log和tail -n 1 audit.log看首尾时间戳（2026 年起多为毫秒级） - 导出的 CSV 中字段顺序不固定，别硬写第 3 列是用户名；先用
head -n 1看 header，再用awk -F'\t' '$5 == "Connect" && $7 == "success" {print $3}'这类带条件的提取 - API 调用有频控和单次上限（常见 Limit=300），要用
DescribeAuditLogFiles先拉文件列表，再逐个请求DownloadUrl，注意 URL 有效期（通常 5 分钟） - 控制台搜索时，“操作类型=Connect”+“状态=success”+“时间范围=过去 180 天”是唯一有效组合，其他字段（如 IP、DB 名）容易漏掉静默连接
删账号前必须验证的三类隐性依赖
DROP USER 不是原子操作，漏查任何一项都可能引发线上故障：
- 活跃连接：
SELECT ID, USER, HOST, COMMAND, TIME FROM information_schema.PROCESSLIST WHERE USER = 'xxx';，有结果必须先KILL，不能等超时 - 代理关系：
SELECT * FROM mysql.proxies_priv WHERE CONCAT(User, '@', Host) = 'xxx@%';，如果其他账号靠它做 PROXY 登录，删了会连锁报错 - DEFINER 依赖：查存储过程、函数、事件、视图里有没有
DEFINER='xxx'@'yyy'，这类对象不会因删用户而失效，但下次调用就报错 —— 用SELECT ROUTINE_NAME, DEFINER FROM information_schema.ROUTINES WHERE DEFINER LIKE 'xxx@%';
真正难的不是查“谁没登录”，而是确认“删了谁也不会断”。很多账号看似闲置，其实是定时备份脚本、监控探针、或者中间件健康检查在用，它们不常连，但一删就告警风暴。建议把清理动作拆成“标记 → 观察一周 → 确认无日志 → 删除”，而不是一次批量扫荡。
