PHP建库无法指定MySQL版本兼容性，真正影响兼容性的是字符集与排序规则；应显式指定utf8mb4及向后兼容的collation（如utf8mb4_unicode_ci），避免使用8.0专属排序规则，并通过版本检测或迁移工具实现多版本适配。
PHP 创建数据库时无法直接指定 MySQL 版本兼容性
MySQL 的版本兼容性由服务端决定，PHP 的 mysqli 或 PDO 只是客户端驱动，执行 CREATE DATABASE 语句时不会、也不能“告诉 MySQL 用哪个版本的语法或默认行为”。所谓“建库设版本兼容”，本质是控制建库后创建的表、字段、索引等对象是否能在目标 MySQL 版本上正常工作。
真正影响兼容性的其实是建库后的字符集与排序规则
MySQL 5.7 和 8.0 对默认 COLLATION 处理差异明显：5.7 默认用 utf8mb4_general_ci，而 8.0 推荐 utf8mb4_0900_ai_ci（且该排序规则在 5.7 中不存在）。如果 PHP 建库时硬写 8.0 特有排序规则，后续在 5.7 环境会报错 Unknown collation: 'utf8mb4_0900_ai_ci'。
- 安全做法：显式指定向后兼容的排序规则，例如
DEFAULT COLLATE utf8mb4_unicode_ci - 避免写死
utf8mb4_0900_ai_ci或utf8mb4_0900_as_cs等 8.0+ 专属值 - 建库语句中不写
COLLATE时，实际取值取决于 MySQL 全局变量collation_database，而该变量又受character_set_server和 MySQL 版本影响——不可控
PHP 中建库语句需适配多版本的实操要点
不要依赖 mysqli::query("CREATE DATABASE ...") 一次性搞定所有环境。更稳妥的方式是分两步，并检查服务端能力：
- 先用
SELECT VERSION()获取 MySQL 实际版本号，再分支处理 - 对 5.7 及以下，用
DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci - 对 8.0+，可选
utf8mb4_0900_ai_ci，但仅当明确需要其大小写/重音敏感特性时才启用 - 避免使用
utf8字符集（它最多只支持 3 字节 UTF-8 字符，无法存 emoji），必须用utf8mb4
示例片段：
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
立即学习“PHP免费学习笔记（深入）”；
$version = $mysqli->query("SELECT VERSION()")->fetch_row()[0];
if (version_compare($version, '8.0.0', '>=')) {
$sql = "CREATE DATABASE `mydb` DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci";
} else {
$sql = "CREATE DATABASE `mydb` DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci";
}
$mysqli->query($sql);
真正的版本控制不在建库语句里，而在迁移脚本中
靠 PHP 一次性建库解决不了长期兼容问题。生产环境应使用数据库迁移工具（如 Laravel Migrations、Phinx、Doctrine DBAL），把建库、建表、改结构全部纳入版本化 SQL 或 PHP 类管理。
- 迁移文件按顺序编号（如
20230101000000_create_users_table.php），天然支持回滚和跨环境同步 - 可在迁移中嵌入版本判断逻辑，例如
if ($this->isMySql8()) { ... } - CI 流程中可并行测试不同 MySQL 版本容器，提前暴露
JSON_CONTAINS、DESCRIBE JSON等 5.7+/8.0+ 特有语法问题
建库只是起点，后续的 CREATE TABLE、ALTER TABLE、函数使用（如 JSON_EXTRACT）、窗口函数等，才是版本兼容的主战场。
