第一反应是查日志定位脚本行号。运行docker logs <container_name> | grep -i "error\|initdb.d"可直接获取如[ERROR] /docker-entrypoint-initdb.d/init.sql:3的精确报错位置，再结合mysql -e本地验证、BOM检查（xxd init.sql | head -n 5）、分段执行及版本兼容性排查，高效解决初始化失败问题。
看日志直接定位到脚本行号
容器启动时初始化失败，第一反应不是改脚本，而是查日志。MySQL容器在执行 /docker-entrypoint-initdb.d/ 下的 SQL 文件时，出错会明确打印文件名和行号。
运行 docker logs <container_name>，再用 grep -i "error\|initdb.d" 过滤，典型输出类似：
[ERROR] /docker-entrypoint-initdb.d/init.sql:3: You have an error in your SQL syntax
这说明问题就在 init.sql 第 3 行——别猜，直接打开该行看。
- 注意：行号从 1 开始计数，且注释行（
--或/* */）也占行，但不参与执行 - 如果日志只报
near '' at line X，说明错误可能在上一行末尾（比如漏了分号或右括号） - 多个脚本按字母序执行，
01-schema.sql出错会导致后续所有脚本跳过
用 mysql -e 本地单行验证
别把整段 SQL 塞进容器反复试。把疑似出错的语句复制出来，用本地 MySQL 客户端快速验证：
mysql -u root -p -e "CREATE DATABASE IF NOT EXISTS app_db CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;"
成功返回即语法无硬伤；失败则立刻暴露真实报错，比如：
-
ERROR 1064 (42000)：说明是纯语法问题（引号不闭、括号不配、关键字拼错） -
ERROR 1146 (42S02)：说明表不存在，但你在INSERT前没建表 -
ERROR 1054 (42S22)：字段名写错，或用了保留字（如order）没加反引号
尤其注意：Shell 变量拼接的 SQL（如 "CREATE TABLE $TABLE_NAME (...)"）必须先 echo 出来再验证，变量为空会导致语法断裂。
检查编码与不可见字符
脚本执行中断但看不出语法问题？很可能是编码惹的祸。Windows 编辑器保存的 UTF-8 文件常带 BOM 头，MySQL 解析器会把它当非法命令。
用 file -i init.sql 查编码：
- 输出含
charset=utf-8是正常；若为charset=iso-8859-1或charset=gbk，需转码 - 用
xxd init.sql | head -n 5看前几字节：开头是ef bb bf就是 BOM，必须去掉 - 修复命令：
sed -i '1s/^\xEF\xBB\xBF//' init.sql（Linux）或用 VS Code 保存为 “UTF-8 无 BOM”
另外，SQL 中混入全角空格、中文分号（；）、长破折号（—）也会触发 ERROR 1064，肉眼难辨，建议用 cat -A init.sql 显式显示所有控制符。
拆解复杂语句并避开版本陷阱
一个包含 CREATE TABLE + INSERT + ALTER 的初始化脚本，哪怕只有一处错，整段都会停在那行。更麻烦的是，MySQL 8.0+ 默认启用 ONLY_FULL_GROUP_BY 和严格模式，某些在 5.7 能跑的模糊写法会直接报错。
- 把脚本按分号切开，逐条粘贴进客户端执行，确认每句都返回
Query OK - 检查是否用了已废弃语法：如
TYPE=MyISAM→ 必须改成ENGINE=InnoDB；password字段 → 8.0+ 应用authentication_string - 用
mysqld --version确认容器内 MySQL 版本，再查对应手册确认语法支持情况
真正卡住的地方，往往不是最复杂的那句，而是最不起眼的一行 INSERT 里少了个单引号，或者 CREATE INDEX 后多打了一个逗号——盯住报错行及其上一行，比通读全文更高效。
