调试 Docker 里 MySQL 的 sql_mode 配置是我这几年在容器化运维里经常被同事拉去帮忙的问题之一。随便一搜就是一堆“docker mysql sql_mode不生效”“改了 my.cnf 没反应”“command 传参无效”的帖子同一个坑翻来覆去地出现。你以为是镜像有问题其实根子就那么几类参数根本没进到 mysqld 进程、配置文件没被读、或者配置被读了但你验证的时机和连接根本不对。这篇文章不打算只丢一个“照抄就能用”的模板而是把从容器启动参数到 MySQL 内部变量的整条链路拆开让你以后再遇到类似问题能按步骤自己定位。1. 先定位你改的是“启动参数”还是“运行参数”1.1 sql_mode 的三条设置路径sql_mode在 MySQL 里就是一个普通系统变量它的最终值取决于两件事启动时 mysqld 解析了哪些选项文件、命令行给了什么参数以及启动之后有没有人用 SQL 手动改过。常见的设置入口有三种命令行参数在docker run镜像名后面追加或者在 Compose 的command字段里写例如--sql-modeSTRICT_TRANS_TABLES,NO_ZERO_DATE。配置文件挂载一个.cnf文件到容器的配置目录例如/etc/mysql/conf.d/sql-mode.cnf在里面写[mysqld]分组的sql_mode...。运行期 SQL连进 MySQL 之后执行SET GLOBAL sql_mode ...MySQL 8.0 还可以用SET PERSIST把它写进持久化文件。很多人会混着用既挂载了配置文件又顺手在客户端里执行了SET GLOBAL。重启后看到配置好像没生效其实是没意识到运行期的手动修改会覆盖配置文件启动时读到的值。或者反过来以为SET GLOBAL是永久修改结果下次容器一重建又被默认配置打回原形。1.2 “不生效”至少有三种不同含义遇到问题别急着改配置先搞清楚你看到的“不生效”到底是哪一种SELECT sql_mode完全没变化还是默认那一长串SELECT GLOBAL.sql_mode已经变了但SELECT sql_mode还是旧值SHOW VARIABLES LIKE sql_mode显示的是新值但应用表现还是老样子。这三种情况对应的原因完全不同。第一种是参数根本没进入 mysqld属于配置传递链路的问题第二种是全局值改了但当前会话还保留着连接建立时的旧快照第三种大概率是应用连接池里的老连接没刷新新值只对之后新建的连接生效。所以排查的第一步从来不是看 Docker 配置而是确定你验证用的连接是从哪来的、什么时候建立的。否则很容易被表面现象带偏。2. 从 docker-entrypoint 到 my.cnf官方镜像到底怎么读配置2.1 配置文件读取顺序官方 MySQL 镜像的文档推荐把自定义配置挂到/etc/mysql/conf.d目录。原因在于容器里的主配置文件有一句类似!includedir /etc/mysql/conf.d/mysqld 启动时按照“先系统级配置、再主配置、再 conf.d 下所有 .cnf、最后命令行参数”的顺序解析选项。同一个选项在后面的位置读取时会覆盖前面的值。配置来源优先级系统级 /etc/my.cnf低/etc/mysql/my.cnf 主配置中/etc/mysql/conf.d/*.cnf中命令行参数高这个优先级顺序也解释了为什么你同时用了 Composecommand和挂载的 my.cnf 时最后生效的往往是命令行参数。如果你是在命令行里写了一个值又在文件里写了另一个值那命令行赢。2.2 入口脚本对参数做了什么官方镜像的docker-entrypoint.sh有一小段逻辑如果容器启动命令的第一个参数以-开头就自动在前面补上mysqld。所以你在docker run后面直接写--sql-modeSTRICT_TRANS_TABLES,NO_ZERO_DATE实际执行时会被变成mysqld --sql-modeSTRICT_TRANS_TABLES,NO_ZERO_DATE入口脚本在数据目录为空时还会做初始化先起一个临时 mysqld执行/docker-entrypoint-initdb.d下的初始化脚本然后关掉临时实例最后把你给的所有参数原样exec给真正的 mysqld。这里有个容易被忽视的坑临时实例同样会带上你传的--sql-mode。如果你给的sql_mode值里带了一个当前版本不认识的模式名初始化阶段就可能直接报错表现不是“不生效”而是容器一直起不来。2.3 用 my_print_defaults 看解析后的配置判断配置到底有没有被 mysqld 读到最直接的办法是在容器里执行docker exec mysql-dev sh -c my_print_defaults mysqld这个命令会读取所有选项文件里[mysqld]分组的配置并打印出来。如果这里能看到你写的--sql-mode...说明文件已经被解析如果看不到说明文件没被读取后面就不用再纠结 MySQL 内部为什么不生效了。再进一步看最终生效值可以跑docker exec mysql-dev sh -c mysqld --verbose --help 2/dev/null | grep -A1 sql-mode这个命令不会启动新实例只是打印“默认值 配置文件解析结果”之后的最终配置然后退出。注意 grep 结果里如果出现 unknown variable 之类的提示要回到日志里看具体错误。3. 逐层验证从 docker inspect 到 MySQL 内部3.1 第一层容器实际执行的命令是什么先看容器到底以什么参数跑的docker inspect mysql-dev --format {{.Config.Entrypoint}} | {{.Config.Cmd}}重点看结果里有没有--sql-mode...。很多次我帮人排查最后发现是 Compose 文件里command写错了层级或者根本写在了另一个无关服务上。再用 Compose 的合并配置确认一遍docker-compose config这个命令会输出所有服务经过默认值合并后的完整定义command字段会原样显示。你可以直接确认自己写的参数有没有出现在最终结果里。3.2 第二层配置文件是否被真正读到检查文件是否存在、后缀是否正确、内容有没有[mysqld]分组docker exec mysql-dev ls -al /etc/mysql/conf.d/ docker exec mysql-dev cat /etc/mysql/conf.d/sql-mode.cnf这里常见的问题有这么几个文件后缀写了.conf或.ini但 MySQL 的!includedir只认.cnf不认的文件会被静默跳过挂载点写到了/etc/mysql/mysql.conf.d而镜像实际读的是/etc/mysql/conf.d直接把自定义文件单独 bind mount 到/etc/mysql/my.cnf把镜像原有的主配置覆盖了主配置里的!includedir /etc/mysql/conf.d/也跟着消失于是整个 conf.d 目录都失效挂载目录权限不对容器内用户读不了文件启动日志里会出现Permission denied。3.3 第三层MySQL 进程视角的最终值即使配置文件被读取了也还要区分全局值和会话值。正确的验证姿势是开一个新连接mysql -uroot -p -N -e SELECT GLOBAL.sql_mode; SELECT SESSION.sql_mode;如果全局是新值、会话是旧值说明连接在变量被改之前就建立了重连一次通常就好。如果你是在同一个客户端里先SET GLOBAL再查SELECT sql_mode你会看到会话值没变。这不是 bug因为SET GLOBAL只改全局值不会动当前会话里已经初始化好的值。启动日志也值得扫一眼docker logs mysql-dev 21 | grep -i sql.mode\|unknown\|permission如果启动阶段写配置失败日志里一定会有错误而不是静默忽略。4. docker-compose 里最容易踩的四个写法坑4.1 command 字符串与 YAML 引号Compose 的command支持字符串和列表两种写法。很多人为了让一个包含等号和逗号的参数在 YAML 里显得“安全”额外加了一层双引号services: mysql: image: mysql:8.0 command: --sql-mode\STRICT_TRANS_TABLES,NO_ZERO_DATE\YAML 解析后这个字符串会变成--sql-modeSTRICT_TRANS_TABLES,NO_ZERO_DATE中间的双引号会被当成参数内容的一部分传给 mysqld最终得到一个非法值。简单问题简单处理直接写command: --sql-modeSTRICT_TRANS_TABLES,NO_ZERO_DATE如果还是担心就显式用列表形式command: - --sql-modeSTRICT_TRANS_TABLES,NO_ZERO_DATE这样每个参数都是独立的字符串不会被奇怪的解析逻辑拆错。4.2 覆盖主配置导致 !includedir 失效官方推荐挂目录到/etc/mysql/conf.d但有些人为了省事把宿主机某个单独的my.cnf直接挂到容器里的/etc/mysql/my.cnf。一旦你这么干容器原本主配置里的!includedir /etc/mysql/conf.d/就被整个替换掉了conf.d 目录下所有文件都不再读取。如果一定要替换主配置记得在自己的文件里手动补上这句!includedir /etc/mysql/conf.d/否则之后你在 conf.d 里怎么改都是白改。4.3 restart 和 recreate 的差别docker restart只是把同一个容器的进程重启容器创建时定的command不会因此改变。你在 Compose 文件里改了command之后如果执行的是docker-compose restart新参数根本没机会进来。正确做法是docker-compose up -d --force-recreate或者至少执行docker-compose up -d让 Compose 检测到配置差异后自动重建容器。这也是“改了半天不生效”的高频原因排查时先问自己一句最近有没有真正重建过容器4.4 空值--sql-mode的写法想清空所有模式时有人会写command: --sql-mode 在 Compose 字符串模式下这个会被拆成--sql-mode和两个参数mysqld 未必能把后面的空字符串当作前面的选项值消费可能出现未知变量或解析异常。稳妥写法是command: --sql-mode一个等号就够了不需要额外加空字符串。5. 看起来像配置问题其实不是的三种情况5.1 连接池复用导致的假不生效应用侧最常见。把SET GLOBAL sql_mode改了之后应用连接池里的连接不会主动刷新老连接还带着连接建立时的 session 值。你手动用新客户端查看到的是新值应用却因为复用了老连接感觉“还是不生效”。验证办法是重启应用或者让连接池释放空闲连接后再观察。生产环境里改这种全局变量最好挑低峰期并且准备好连接池热重启的方案。5.2 sql_mode 值里有当前版本不认的模式不同版本的 sql_mode 模式集合不一样。MySQL 8.0 里NO_AUTO_CREATE_USER早就被移除了5.7 的老配置直接搬过来会得到类似这样的报错Variable sql_mode cant be set to the value of NO_AUTO_CREATE_USER遇到这种错误不是不生效而是启动失败或者初始化临时实例失败。把日志翻出来按版本去掉不认识的项就好。还有像NO_FIELD_OPTIONS、NO_KEY_OPTIONS这些更老的模式在 8.0 里也都不存在了。5.3 你查的根本不是同一个实例排查到最后一层的经典场景宿主机上有两个 MySQL 容器一个映射 3306一个映射 3307你改了 3307 的配置但客户端连的是 3306。或者之前实验残留的旧容器还没删端口又被新的占用了你以为连的是新实例实际连的是老古董。这种问题出现的频率远比你想象的高。看到docker ps的完整输出再下结论永远比盯着配置文件猜要快。6. 推荐配置模板与五分钟验证清单6.1 方案 A挂载配置文件推荐宿主机准备mysql/conf.d/sql-mode.cnf内容如下[mysqld] sql_modeONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTIONCompose 片段services: mysql: image: mysql:8.0 container_name: mysql-dev environment: MYSQL_ROOT_PASSWORD: rootpass volumes: - ./mysql/conf.d:/etc/mysql/conf.d:ro - mysql_data:/var/lib/mysql volumes: mysql_data:6.2 方案 B命令行传参适合快速验证services: mysql: image: mysql:8.0 command: --sql-modeONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION这种写法适合临时调试缺点是配置分散在启动命令里团队协作时不如配置文件直观。6.3 方案 C运行期 PERSIST不方便改容器时MySQL 8.0 支持把系统变量持久化到数据目录里的mysqld-auto.cnfSET PERSIST sql_mode ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION;这样下次重启也会自动加载不需要动容器配置。想撤销就执行RESET PERSIST sql_mode;注意SET PERSIST修改的是运行中的全局值和连接池的坑一样老连接不会立刻刷新生效。6.4 验证清单按顺序执行每一步有明确结果再进入下一步用docker inspect和docker-compose config确认容器启动参数和 Compose 合并结果进入容器确认配置目录下存在.cnf文件且内容可读执行my_print_defaults mysqld确认配置已被解析用全新连接查看GLOBAL.sql_mode和SESSION.sql_mode查看启动日志确认没有关于 sql_mode 的报错。我自己在实际排查中体会最深的一点是绝大多数 sql_mode “不生效”都不是 MySQL 或 Docker 出了什么玄学问题而是配置传递链路上某一环没走通。要么是 Compose 的 command 没写对要么是配置文件没挂到被读取的位置要么是验证时用了老连接。把这五步养成习惯基本十分钟内就能定位。最后分享一个小技巧把上面第 3 步和第 4 步的命令拼成一个 shell 函数放到自己的常用脚本里下次改完配置直接一键验证比反复敲 docker exec 省事得多。 
长河君 · 2026/10/14 4:43:00 · 阅读 1.2k Docker中MySQL sql_mode不生效？一条链路排查配置传递与验证
调试 Docker 里 MySQL 的 sql_mode 配置是我这几年在容器化运维里经常被同事拉去帮忙的问题之一。随便一搜就是一堆“docker mysql sql_mode不生效”“改了 my.cnf 没反应”“command 传参无效”的帖子同一个坑翻来覆去地出现。你以为是镜像有问题其实根子就那么几类参数根本没进到 mysqld 进程、配置文件没被读、或者配置被读了但你验证的时机和连接根本不对。这篇文章不打算只丢一个“照抄就能用”的模板而是把从容器启动参数到 MySQL 内部变量的整条链路拆开让你以后再遇到类似问题能按步骤自己定位。1. 先定位你改的是“启动参数”还是“运行参数”1.1 sql_mode 的三条设置路径sql_mode在 MySQL 里就是一个普通系统变量它的最终值取决于两件事启动时 mysqld 解析了哪些选项文件、命令行给了什么参数以及启动之后有没有人用 SQL 手动改过。常见的设置入口有三种命令行参数在docker run镜像名后面追加或者在 Compose 的command字段里写例如--sql-modeSTRICT_TRANS_TABLES,NO_ZERO_DATE。配置文件挂载一个.cnf文件到容器的配置目录例如/etc/mysql/conf.d/sql-mode.cnf在里面写[mysqld]分组的sql_mode...。运行期 SQL连进 MySQL 之后执行SET GLOBAL sql_mode ...MySQL 8.0 还可以用SET PERSIST把它写进持久化文件。很多人会混着用既挂载了配置文件又顺手在客户端里执行了SET GLOBAL。重启后看到配置好像没生效其实是没意识到运行期的手动修改会覆盖配置文件启动时读到的值。或者反过来以为SET GLOBAL是永久修改结果下次容器一重建又被默认配置打回原形。1.2 “不生效”至少有三种不同含义遇到问题别急着改配置先搞清楚你看到的“不生效”到底是哪一种SELECT sql_mode完全没变化还是默认那一长串SELECT GLOBAL.sql_mode已经变了但SELECT sql_mode还是旧值SHOW VARIABLES LIKE sql_mode显示的是新值但应用表现还是老样子。这三种情况对应的原因完全不同。第一种是参数根本没进入 mysqld属于配置传递链路的问题第二种是全局值改了但当前会话还保留着连接建立时的旧快照第三种大概率是应用连接池里的老连接没刷新新值只对之后新建的连接生效。所以排查的第一步从来不是看 Docker 配置而是确定你验证用的连接是从哪来的、什么时候建立的。否则很容易被表面现象带偏。2. 从 docker-entrypoint 到 my.cnf官方镜像到底怎么读配置2.1 配置文件读取顺序官方 MySQL 镜像的文档推荐把自定义配置挂到/etc/mysql/conf.d目录。原因在于容器里的主配置文件有一句类似!includedir /etc/mysql/conf.d/mysqld 启动时按照“先系统级配置、再主配置、再 conf.d 下所有 .cnf、最后命令行参数”的顺序解析选项。同一个选项在后面的位置读取时会覆盖前面的值。配置来源优先级系统级 /etc/my.cnf低/etc/mysql/my.cnf 主配置中/etc/mysql/conf.d/*.cnf中命令行参数高这个优先级顺序也解释了为什么你同时用了 Composecommand和挂载的 my.cnf 时最后生效的往往是命令行参数。如果你是在命令行里写了一个值又在文件里写了另一个值那命令行赢。2.2 入口脚本对参数做了什么官方镜像的docker-entrypoint.sh有一小段逻辑如果容器启动命令的第一个参数以-开头就自动在前面补上mysqld。所以你在docker run后面直接写--sql-modeSTRICT_TRANS_TABLES,NO_ZERO_DATE实际执行时会被变成mysqld --sql-modeSTRICT_TRANS_TABLES,NO_ZERO_DATE入口脚本在数据目录为空时还会做初始化先起一个临时 mysqld执行/docker-entrypoint-initdb.d下的初始化脚本然后关掉临时实例最后把你给的所有参数原样exec给真正的 mysqld。这里有个容易被忽视的坑临时实例同样会带上你传的--sql-mode。如果你给的sql_mode值里带了一个当前版本不认识的模式名初始化阶段就可能直接报错表现不是“不生效”而是容器一直起不来。2.3 用 my_print_defaults 看解析后的配置判断配置到底有没有被 mysqld 读到最直接的办法是在容器里执行docker exec mysql-dev sh -c my_print_defaults mysqld这个命令会读取所有选项文件里[mysqld]分组的配置并打印出来。如果这里能看到你写的--sql-mode...说明文件已经被解析如果看不到说明文件没被读取后面就不用再纠结 MySQL 内部为什么不生效了。再进一步看最终生效值可以跑docker exec mysql-dev sh -c mysqld --verbose --help 2/dev/null | grep -A1 sql-mode这个命令不会启动新实例只是打印“默认值 配置文件解析结果”之后的最终配置然后退出。注意 grep 结果里如果出现 unknown variable 之类的提示要回到日志里看具体错误。3. 逐层验证从 docker inspect 到 MySQL 内部3.1 第一层容器实际执行的命令是什么先看容器到底以什么参数跑的docker inspect mysql-dev --format {{.Config.Entrypoint}} | {{.Config.Cmd}}重点看结果里有没有--sql-mode...。很多次我帮人排查最后发现是 Compose 文件里command写错了层级或者根本写在了另一个无关服务上。再用 Compose 的合并配置确认一遍docker-compose config这个命令会输出所有服务经过默认值合并后的完整定义command字段会原样显示。你可以直接确认自己写的参数有没有出现在最终结果里。3.2 第二层配置文件是否被真正读到检查文件是否存在、后缀是否正确、内容有没有[mysqld]分组docker exec mysql-dev ls -al /etc/mysql/conf.d/ docker exec mysql-dev cat /etc/mysql/conf.d/sql-mode.cnf这里常见的问题有这么几个文件后缀写了.conf或.ini但 MySQL 的!includedir只认.cnf不认的文件会被静默跳过挂载点写到了/etc/mysql/mysql.conf.d而镜像实际读的是/etc/mysql/conf.d直接把自定义文件单独 bind mount 到/etc/mysql/my.cnf把镜像原有的主配置覆盖了主配置里的!includedir /etc/mysql/conf.d/也跟着消失于是整个 conf.d 目录都失效挂载目录权限不对容器内用户读不了文件启动日志里会出现Permission denied。3.3 第三层MySQL 进程视角的最终值即使配置文件被读取了也还要区分全局值和会话值。正确的验证姿势是开一个新连接mysql -uroot -p -N -e SELECT GLOBAL.sql_mode; SELECT SESSION.sql_mode;如果全局是新值、会话是旧值说明连接在变量被改之前就建立了重连一次通常就好。如果你是在同一个客户端里先SET GLOBAL再查SELECT sql_mode你会看到会话值没变。这不是 bug因为SET GLOBAL只改全局值不会动当前会话里已经初始化好的值。启动日志也值得扫一眼docker logs mysql-dev 21 | grep -i sql.mode\|unknown\|permission如果启动阶段写配置失败日志里一定会有错误而不是静默忽略。4. docker-compose 里最容易踩的四个写法坑4.1 command 字符串与 YAML 引号Compose 的command支持字符串和列表两种写法。很多人为了让一个包含等号和逗号的参数在 YAML 里显得“安全”额外加了一层双引号services: mysql: image: mysql:8.0 command: --sql-mode\STRICT_TRANS_TABLES,NO_ZERO_DATE\YAML 解析后这个字符串会变成--sql-modeSTRICT_TRANS_TABLES,NO_ZERO_DATE中间的双引号会被当成参数内容的一部分传给 mysqld最终得到一个非法值。简单问题简单处理直接写command: --sql-modeSTRICT_TRANS_TABLES,NO_ZERO_DATE如果还是担心就显式用列表形式command: - --sql-modeSTRICT_TRANS_TABLES,NO_ZERO_DATE这样每个参数都是独立的字符串不会被奇怪的解析逻辑拆错。4.2 覆盖主配置导致 !includedir 失效官方推荐挂目录到/etc/mysql/conf.d但有些人为了省事把宿主机某个单独的my.cnf直接挂到容器里的/etc/mysql/my.cnf。一旦你这么干容器原本主配置里的!includedir /etc/mysql/conf.d/就被整个替换掉了conf.d 目录下所有文件都不再读取。如果一定要替换主配置记得在自己的文件里手动补上这句!includedir /etc/mysql/conf.d/否则之后你在 conf.d 里怎么改都是白改。4.3 restart 和 recreate 的差别docker restart只是把同一个容器的进程重启容器创建时定的command不会因此改变。你在 Compose 文件里改了command之后如果执行的是docker-compose restart新参数根本没机会进来。正确做法是docker-compose up -d --force-recreate或者至少执行docker-compose up -d让 Compose 检测到配置差异后自动重建容器。这也是“改了半天不生效”的高频原因排查时先问自己一句最近有没有真正重建过容器4.4 空值--sql-mode的写法想清空所有模式时有人会写command: --sql-mode 在 Compose 字符串模式下这个会被拆成--sql-mode和两个参数mysqld 未必能把后面的空字符串当作前面的选项值消费可能出现未知变量或解析异常。稳妥写法是command: --sql-mode一个等号就够了不需要额外加空字符串。5. 看起来像配置问题其实不是的三种情况5.1 连接池复用导致的假不生效应用侧最常见。把SET GLOBAL sql_mode改了之后应用连接池里的连接不会主动刷新老连接还带着连接建立时的 session 值。你手动用新客户端查看到的是新值应用却因为复用了老连接感觉“还是不生效”。验证办法是重启应用或者让连接池释放空闲连接后再观察。生产环境里改这种全局变量最好挑低峰期并且准备好连接池热重启的方案。5.2 sql_mode 值里有当前版本不认的模式不同版本的 sql_mode 模式集合不一样。MySQL 8.0 里NO_AUTO_CREATE_USER早就被移除了5.7 的老配置直接搬过来会得到类似这样的报错Variable sql_mode cant be set to the value of NO_AUTO_CREATE_USER遇到这种错误不是不生效而是启动失败或者初始化临时实例失败。把日志翻出来按版本去掉不认识的项就好。还有像NO_FIELD_OPTIONS、NO_KEY_OPTIONS这些更老的模式在 8.0 里也都不存在了。5.3 你查的根本不是同一个实例排查到最后一层的经典场景宿主机上有两个 MySQL 容器一个映射 3306一个映射 3307你改了 3307 的配置但客户端连的是 3306。或者之前实验残留的旧容器还没删端口又被新的占用了你以为连的是新实例实际连的是老古董。这种问题出现的频率远比你想象的高。看到docker ps的完整输出再下结论永远比盯着配置文件猜要快。6. 推荐配置模板与五分钟验证清单6.1 方案 A挂载配置文件推荐宿主机准备mysql/conf.d/sql-mode.cnf内容如下[mysqld] sql_modeONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTIONCompose 片段services: mysql: image: mysql:8.0 container_name: mysql-dev environment: MYSQL_ROOT_PASSWORD: rootpass volumes: - ./mysql/conf.d:/etc/mysql/conf.d:ro - mysql_data:/var/lib/mysql volumes: mysql_data:6.2 方案 B命令行传参适合快速验证services: mysql: image: mysql:8.0 command: --sql-modeONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION这种写法适合临时调试缺点是配置分散在启动命令里团队协作时不如配置文件直观。6.3 方案 C运行期 PERSIST不方便改容器时MySQL 8.0 支持把系统变量持久化到数据目录里的mysqld-auto.cnfSET PERSIST sql_mode ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION;这样下次重启也会自动加载不需要动容器配置。想撤销就执行RESET PERSIST sql_mode;注意SET PERSIST修改的是运行中的全局值和连接池的坑一样老连接不会立刻刷新生效。6.4 验证清单按顺序执行每一步有明确结果再进入下一步用docker inspect和docker-compose config确认容器启动参数和 Compose 合并结果进入容器确认配置目录下存在.cnf文件且内容可读执行my_print_defaults mysqld确认配置已被解析用全新连接查看GLOBAL.sql_mode和SESSION.sql_mode查看启动日志确认没有关于 sql_mode 的报错。我自己在实际排查中体会最深的一点是绝大多数 sql_mode “不生效”都不是 MySQL 或 Docker 出了什么玄学问题而是配置传递链路上某一环没走通。要么是 Compose 的 command 没写对要么是配置文件没挂到被读取的位置要么是验证时用了老连接。把这五步养成习惯基本十分钟内就能定位。最后分享一个小技巧把上面第 3 步和第 4 步的命令拼成一个 shell 函数放到自己的常用脚本里下次改完配置直接一键验证比反复敲 docker exec 省事得多。