初始化脚本该放哪、怎么执行最稳妥
MySQL 数据初始化脚本本质是 SQL 文件，核心目标是：在空库或指定库中一次性执行建表、插入基础数据、设权限等操作。不推荐在应用启动时动态执行 DDL（比如用 ORM 的 migrate），尤其对生产环境——失败难回滚、无日志追溯、易和业务逻辑耦合。
推荐做法是把
init.sql或
schema.sql+
data.sql放进项目
sql/目录下，由部署流程显式调用
mysql命令执行。 确保目标数据库已存在，且连接用户有
CREATE、
INSERT权限（避免用
root直连） 脚本开头加
USE `dbname`;，不要依赖命令行参数指定库名，否则跨环境易错 所有表名、字段名统一用反引号包裹，如
`user_info`，防止关键字冲突（如
order、
group） 插入语句用
INSERT IGNORE或
REPLACE INTO处理重复主键，避免初始化失败
如何让 init.sql 支持多环境（dev/test/prod）
纯 SQL 本身不支持变量，硬编码库名、IP、密码会污染脚本。实际方案是「模板 + 渲染」而非「SQL 里写 if」。
常见做法：
用envsubst（Linux/macOS）或
sed替换占位符，例如脚本中写
CREATE DATABASE `${DB_NAME}`;，部署前执行 envsubst init.sql用 Python/Shell 脚本生成最终 SQL，读取
.env文件注入值，比纯 sed 更健壮 禁止在 SQL 中写
SELECT @@hostname或
IF EXISTS判断环境——MySQL 初始化阶段不可靠，且不同版本语法差异大
执行失败常见原因和快速定位方法
执行
mysql -u user -p -h host 后没报错但表没建好？大概率是以下几种情况：脚本末尾缺
;导致最后一条语句被忽略（尤其最后一行是
INSERT） 字符集不一致：
init.sql是 UTF-8-BOM 编码，MySQL 默认不识别 BOM，会把第一行解析成乱码并报错
Unknown command '\xef'—— 用
file init.sql检查，用
iconv -f UTF-8-BOM -t UTF-8 init.sql > init_clean.sql转换 权限不足：报错
Access denied for user 'xxx'@'%' to database 'yyy'，说明用户没被授权操作该库，需先用 root 执行
GRANT ALL ON `yyy`.* TO 'xxx'@'%'; FLUSH PRIVILEGES;引擎不支持：脚本写了
ENGINE=InnoDB ROW_FORMAT=COMPRESSED，但 MySQL 5.6 以下不支持
COMPRESSED，直接报错退出
Docker 环境下自动初始化的正确姿势
Docker 官方 MySQL 镜像（
mysql:8.0）支持自动执行
/docker-entrypoint-initdb.d/下的
.sh或
.sql文件，但有几个关键限制： 只在容器首次启动、且数据卷为空时触发；重启容器不会重跑 —— 这是设计行为，不是 bug SQL 文件必须是 UTF-8 无 BOM，且以
.sql结尾（
.sql.gz不支持） 不能依赖外部服务（比如先等 Redis 启动），因为 init 阶段 MySQL 还没完全就绪，
localhost连接可能失败 如果需要复杂逻辑（如根据环境变量创建不同表结构），写成
.sh脚本更合适，里面用
mysql -e "CREATE TABLE ..."显式执行
#!/bin/bash
# /docker-entrypoint-initdb.d/01-init.sh
set -e
mysql -u root -p"$MYSQL_ROOT_PASSWORD" <<-EOSQL
CREATE DATABASE IF NOT EXISTS \`$MYSQL_DATABASE\`;
USE \`$MYSQL_DATABASE\`;
CREATE TABLE IF NOT EXISTS \`config\` (
\`key\` VARCHAR(64) PRIMARY KEY,
\`value\` TEXT
) ENGINE=InnoDB;
EOSQL真正容易被忽略的是：Docker Compose 中挂载的
volumes如果指向已有数据目录，init 脚本根本不会执行——得删掉 volume 再试，或者改用
command覆盖默认启动命令手动触发。
