服务器莫名多出的数据库，多数不是“自己长出来”的，而是自动化脚本、应用安装初始化、云控制台误操作或历史遗留任务留下的痕迹，先查数据库创建时间，再对齐账号、进程和审计日志，基本能锁定创建者。
数据库不会凭空长出一个“抽屉”，它要么有人放进去，要么有程序按计划放进去，排查时先别急着删库，也别急着改密码，现场证据一旦被覆盖，后面只能靠猜。
服务器多了一个数据库怎么查是谁创建的？先锁定创建时间与账号
第一步是取证,不是处置，把库名、大小、创建时间、当前连接账号记下来，MySQL 里可以先用下面几条命令看个大概：
SHOW DATABASES; SELECT table_schema, MIN(create_time) AS first_table_time FROM information_schema.tables GROUP BY table_schema; SELECT user, host, account_locked FROM mysql.user; SHOW PROCESSLIST;
information_schema.tables 里的 create_time 是表级时间，空库没有表，查不到，这时要看数据目录的文件时间：
ls -ld --time=birth /var/lib/mysql/库名 stat /var/lib/mysql/库名
Linux 文件系统如果能记录 birth time，就能给出接近库创建的时间，再配合 binlog 里的 CREATE DATABASE 事件，时间线会更清楚：
mysqlbinlog --base64-output=DECODE-ROWS -v binlog.000001 | grep -i "create database"
账号侧重点看三件事：有没有新用户、新授权、异常来源主机，创建数据库的人，往往也会顺手建账号或改权限。mysql.user 里出现陌生 host，要单独标记。
云服务器数据库被自动创建怎么办？从控制台审计入手
云上分两种,一种是云主机自建 MySQL，另一种是云托管数据库，后者不能登主机看文件，排查入口在控制台，简米云可查 ActionTrail 操作审计，酷番云可查 CloudAudit，AWS 可查 CloudTrail，重点筛 CreateDatabase、CreateDBInstance、CreateAccount 这类 API 调用，看调用时间、调用者、来源 IP。
云托管数据库还要看关联服务,数据迁移、备份恢复、只读实例、数据订阅、DTS 任务，都可能产生新库，控制台里显示“服务账号创建”，不等于入侵，服务账号背后可能是资源编排、自动扩缩容或某个 SaaS 连接器，把 API 调用记录和资源编排记录对上，才能判断是“人点的”还是“程序跑的”。
本地服务器和云服务器数据库多出来对比：排查路径不同
| 服务器类型 | 多出数据库的常见来源 | 第一核查入口 | 注意点 |
|---|---|---|---|
| 本地物理机自建 MySQL | 安装包初始化、测试脚本、人工误操作 | 数据目录文件时间、bash 历史、cron | 日志可能被轮转，要尽快取证 |
| 云主机自建 MySQL | 自动化部署、应用安装、安全事件 | binlog、命令历史、VPC 流日志 | 安全组变更也要看 |
| 云托管数据库 | 控制台/API 操作、备份恢复、迁移任务 | 云审计、任务记录、账号授权 | 看不到主机文件，审计日志更关键 |
有些人会问数据库多了一个排查要多少钱,外部应急通常按人天或按次计费，先做完上面的时间线和账号核对，能明显减少无效工时，北京服务器数据库多了一个找谁处理，优先走云厂商工单和本地安全服务商，但工单提交前要准备好库名、创建时间、可疑账号和 SQL 记录，否则对方也只能从零开始查。
三类“嫌疑人”逐一排除：脚本、应用、人
自动化脚本和运维工具
Terraform、Ansible、Kubernetes Operator、CI/CD 流水线、备份恢复任务，都可能建库，查 cron 和 systemd timers：
crontab -l ls -la /etc/cron. systemctl list-timers --all
Kubernetes 环境看事件：
kubectl get events -A --sort-by=.lastTimestamp
如果库名带环境前缀,app_test、app_staging，大概率是部署脚本或测试流水线留下的，把库创建时间和最近一次发布记录对齐，往往能直接定位到某次 CI 任务。
应用安装包和第三方服务
WordPress、GitLab、Jenkins、监控 Agent、SaaS 连接器，安装时常常自动建库，特征是库名和业务命名规则接近，字符集、排序规则也一致，查应用配置文件里的数据库连接串，看有没有指向这个新库，再看应用日志里的初始化记录，第三方服务建库通常有固定周期，比如每天同步一次，时间点很规律。
人为误操作与安全事件
控制台误点、测试库忘了删、弱口令被扫，都会留下新库，安全事件的特征更明显：库名随机、新建高权限账号、异常 IP 登录、对外发起连接，查 SSH 登录失败记录和数据库审计：
lastb journalctl -u sshd --since "7 days ago"
MySQL 如果开了审计插件，直接筛 CREATE_DATABASE，没开审计，就看 binlog 和 general log，general log 默认不开，没开就只能靠 binlog 和时间线反推，安全事件先隔离网络，保留证据，再改密码，顺序反了，日志可能被覆盖。
一套可复现的取证流程
按顺序执行,别跳步：
- 记录现场：库名、大小、创建时间、当前连接、账号列表。
- 查数据目录文件时间,和 binlog 的建库事件对齐。
- 查系统命令历史：
/root/.bash_history、/root/.mysql_history。 - 查自动化任务：cron、systemd timers、CI/CD 发布记录、K8s 事件。
- 查云审计：控制台 API 调用、RAM 账号、来源 IP。
- 查应用日志：安装记录、初始化脚本、连接串变更。
- 做时间线表：数据库事件、系统事件、账号事件放在同一张表里。
- 处置：备份、禁用可疑账号、关闭公网访问、补审计。
时间线表可以这样列：
| 时间点 | 数据库事件 | 系统事件 | 可疑来源 |
|---|---|---|---|
| 某日 02:00 | 新建库 tmp_xxx |
cron 任务执行 | 部署脚本 |
| 某日 10:15 | 新建账号 backup |
控制台 API 调用 | 运维账号 |
| 某日 23:40 | 库被清空 | 异常 IP 登录 | 待确认 |
表格不用一次填满,先把已知时间点放进去，缺口就是下一步要查的方向。
找到创建者后怎么收尾
不要只删库,先确认库有没有被业务引用，查连接串、查 SHOW PROCESSLIST、查应用日志，确认无依赖后再备份删除，补三类监控：数据库数量变化告警、账号变更告警、审计日志开启，行业共识认为，数据库资产应纳入 CMDB 统一管理，新建库要有审批和命名规范，业内专家指出，云上操作审计是溯源关键，日志保留周期要覆盖至少一个完整发布周期，据工信部公开的云服务安全相关规范，云服务商应保留必要的操作日志，用户侧也要开启自身审计能力。
多出来的数据库像一条脚印,创建时间、账号和审计日志就是脚印的方向，先取证再处置，比直接删库更接近真相。
关于服务器莫名多了一个数据库是谁创建的？Q&A
Q1：数据库创建时间查不到怎么办？
空库没有表,information_schema.tables 给不出时间，改查数据目录文件时间、binlog 里的 CREATE DATABASE 事件、云审计日志，三路交叉，通常能还原到小时级。
Q2：云控制台显示创建者是服务账号，是不是被入侵了？
不一定,服务账号可能是自动化工具、资源编排或云服务关联角色，先查 API 调用记录和任务记录，服务账号有创建行为，只说明“程序干的”，还要看这个程序是否被允许。
Q3：多出来的数据库可以直接删吗？
先备份,再查连接，用 SHOW PROCESSLIST 和业务配置确认没有依赖，删除前完成备份和连接排查，这两件事没有捷径。