17370845950

MySQL初始化脚本执行前须确认：1.mysqld进程已启动且监听3306端口；2.脚本不含CREATE USER/GRANT语句（除非用--init-file启动或手动登录）；3.脚本首行不可写#!/usr/bin/env mysql。

MySQL 初始化脚本执行前必须确认的三件事

脚本不是丢进命令行就能跑通的——多数失败源于权限、上下文或 MySQL 状态没对齐。

• mysqld 进程必须已启动，且监听本地 3306（或你配置的端口），mysqladmin ping 能返回 mysqld is alive
• 初始化脚本里不能含 CREATE USER 或 GRANT 语句，除非你已用 --init-file 启动或手动登录后执行；默认 root 密码为空时，直接 mysql -u root 才能连上
• 脚本第一行别写 #!/usr/bin/env mysql —— MySQL 不是解释器，这种 shebang 会被忽略，甚至导致语法错误

用 mysql 命令行直接执行 SQL 文件的正确姿势

这是最常用也最

容易出错的方式：路径、字符集、连接参数稍有偏差，就报 ERROR 1045 (28000) 或乱码插入。

• 确保文件是 UTF-8 编码（无 BOM），否则中文注释或字段值可能触发 Incorrect string value
• 显式指定连接参数，避免依赖 my.cnf 默认值：mysql -u root -p -h 127.0.0.1 -P 3306 --default-character-set=utf8mb4
• 如果脚本含多个 USE db_name，建议每个语句后加 ; 并换行；MySQL 在管道中对空行和注释更敏感，--comments 参数不解决执行问题

docker 中初始化 MySQL 容器时自动运行脚本的限制

Docker 官方镜像（mysql:8.0）只认 /docker-entrypoint-initdb.d/ 下的 .sql、.sql.gz 或 .sh 文件，但行为有隐含规则。

• 仅在容器首次启动、且数据卷为空时执行；重启容器或挂载已有数据卷，脚本完全被跳过
• .sh 脚本必须以 #!/bin/bash 开头，且最终调用 mysql -u root -e "..."，不能直接 echo SQL 到 stdout
• 如果脚本里创建了数据库，记得在 CREATE DATABASE 后立刻 USE，否则后续 CREATE TABLE 会报 No database selected

初始化失败后如何快速定位是脚本问题还是环境问题

别急着重跑整个流程，先分层验证。

• 用 mysql -u root -e "SELECT VERSION();" 确认连接可用；若失败，问题在认证或网络，不是脚本本身
• 把 init.sql 拆成单条语句，逐条粘贴进 mysql -u root 交互终端，观察哪一行报错（比如 DATETIME 字段在 5.6 里不支持 DEFAULT CURRENT_TIMESTAMP）
• 检查 MySQL 错误日志：tail -n 50 /var/log/mysql/error.log（Linux）或 docker logs ，里面常有比客户端更具体的提示，如 Unknown collation: 'utf8mb4_0900_as_cs'（说明用了 8.0 特有排序规则，但服务端是 5.7）

实际初始化中最容易被忽略的，是字符集与排序规则的版本兼容性，以及 docker 场景下“只执行一次”的静默行为。这两点一旦出错，现象毫无征兆，排查成本远高于提前加一行 SHOW VARIABLES LIKE 'character_set%';。