Unknown database 'xxx' 错误是 MySQL 服务端因未找到指定数据库名而返回的明确提示，根源在于数据库未创建、库名拼写错误、大小写不匹配、权限不足或配置环境错位。
MySQL 报错 Unknown database 'xxx' 的直接原因
这个错误不是 PHP 本身的问题，而是 MySQL 服务端明确告诉你：它根本没找到你指定的数据库名。PHP 的 mysqli_connect() 或 PDO 只是把你的连接请求（含数据库名）原样发给 MySQL，MySQL 查无此库，就返回这个错误。
常见触发场景包括：
- 数据库确实没创建，比如刚部署完 PHP 程序但忘了执行
CREATE DATABASE `xxx`; - 数据库名拼写错误，大小写不一致（Linux 下 MySQL 数据库名默认区分大小写）
- 连接时指定了数据库名，但该库存在却属于另一个 MySQL 用户权限范围，导致不可见
- 配置文件里写的是测试环境数据库名（如
myapp_dev），但实际连的是生产 MySQL 实例
确认数据库是否存在且可访问的三步检查法
别急着改代码，先用命令行或工具直连 MySQL 验证底层状态：
- 用 root 或有权限的账号登录：
mysql -u root -p，然后执行SHOW DATABASES;，看目标库名是否在列表中 - 如果存在，再查权限：
SELECT User,Host FROM mysql.db WHERE Db='your_db_name';，确认当前 PHP 连接所用的用户名（如'phpuser'@'localhost'）是否在此结果中 - 若数据库不存在，手动创建：
CREATE DATABASE `your_db_name` CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;（注意反引号包裹，避免关键字冲突）
PHP 连接代码中数据库名传参的典型错误
很多开发者把数据库名硬编码进 mysqli_connect() 第四个参数，或 PDO 的 DSN 中，一旦写错就直接报 Unknown database：
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
立即学习“PHP免费学习笔记（深入）”；
// ❌ 错误示例：库名拼错或变量未定义
$mysqli = new mysqli('localhost', 'user', 'pass', 'my_app_db'); // 实际库名是 myapp_db
// ✅ 正确做法：用常量或配置项统一管理，加一层校验
$db_name = defined('DB_NAME') ? DB_NAME : 'myapp_db';
if (!in_array($db_name, $available_dbs)) {
die("Database '$db_name' is not allowed.");
}
$mysqli = new mysqli('localhost', 'user', 'pass', $db_name);
使用 PDO 时也同理，DSN 中的 dbname=xxx 必须与真实库名完全一致：
- 不要在 DSN 中漏掉
dbname=前缀，mysql:host=localhost;dbname=myapp_db是对的，mysql:host=localhost;myapp_db是错的 - 如果连接时不指定数据库（即 DSN 不含
dbname），后续必须用$pdo->exec("USE myapp_db")切库，否则所有查询都会报错
多环境配置下最容易忽略的细节
本地开发连 localhost 的 test_db，上线后却还读着同一份配置，而生产 MySQL 实例里压根没有 test_db —— 这类问题往往卡住一整天。
- 确保
.env或config.php中的DB_NAME值与目标环境实际数据库名严格一致 - 用
echo或日志临时输出你实际传给连接函数的数据库名：error_log("Connecting to DB: " . $db_name); - Docker 环境要注意：PHP 容器里连的
mysql主机名，对应的是 MySQL 容器的 service 名，不是localhost；但数据库名仍是 MySQL 内部定义的那个名字，和容器网络无关
真正麻烦的不是报错本身，而是错误信息里不提示“你连的是哪台 MySQL”，只说“库不存在”——所以第一步永远得确认：你连对服务器了吗？那台服务器上真有这个库吗？
