Docker Compose 是解决团队 MySQL 开发环境不一致的最小可行标准，需在 docker-compose.yml 中显式声明 sql-mode、字符集、排序规则及初始化脚本，并通过 init.sql 统一创建用户、授权与库编码，配合客户端连接参数校准，最后自动化验证四类核心配置。
用 Docker Compose 快速拉起标准化 MySQL 实例
团队本地开发环境不一致，根源常是 MySQL 版本、字符集、SQL 模式不统一。Docker Compose 是最轻量且可复现的解法，不是“推荐试试”，而是事实上的最小可行标准。
关键不在容器本身，而在 docker-compose.yml 里显式声明所有影响行为的参数。比如默认 mysql:8.0 镜像启用严格模式和 utf8mb4_0900_as_cs 排序规则，但开发中常需兼容旧应用逻辑——这时必须覆盖。
-
command要显式指定--sql-mode="STRICT_TRANS_TABLES,NO_ZERO_DATE"，避免依赖镜像默认值 -
environment中强制设置MYSQl_COLLATION_SERVER=utf8mb4_unicode_ci和MYSQl_CHARACTER_SET_SERVER=utf8mb4 -
volumes映射初始化 SQL 到/docker-entrypoint-initdb.d/，确保每次重建都执行建库/授权脚本
version: '3.8'
services:
mysql-dev:
image: mysql:8.0.33
command: --sql-mode="STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,ERROR_FOR_DIVISION_BY_ZERO"
environment:
MYSQL_ROOT_PASSWORD: devpass
MYSQL_DATABASE: myapp_dev
MYSQL_COLLATION_SERVER: utf8mb4_unicode_ci
MYSQL_CHARACTER_SET_SERVER: utf8mb4
ports:
- "3306:3306"
volumes:
- ./init.sql:/docker-entrypoint-initdb.d/init.sql:roinit.sql 里必须包含的三类语句
光有容器不够，初始化脚本才是团队规范落地的第一道关卡。它不是“创建数据库”那么简单，而是把权限、基础结构、安全边界一次性写死。
很多团队漏掉 CREATE USER 或用 root 直连开发，导致后续迁移时权限模型错乱；也有人在脚本里写 SET NAMES utf8，但这对连接层无效，纯属误导。
- 用
CREATE USER 'dev'@'%' IDENTIFIED BY 'dev123';建专用账号，禁止 root 开发直连 - 用
GRANT SELECT,INSERT,UPDATE,DELETE ON myapp_dev.* TO 'dev'@'%';限制 DML 范围，禁用 DROP / CREATE - 用
ALTER DATABASE myapp_dev CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci;显式覆盖库级编码，比连接参数更可靠
客户端连接字符串里的隐藏陷阱
开发用的 JDBC URL、ORM 配置或 GUI 工具连接串，往往悄悄绕过服务端设置。比如 MySQL 8 默认要求 sslMode=REQUIRED，但本地开发根本不需要 SSL——不显式关掉就会连不上。
感谢您选择使用ERMEB域名授权离线网络验证系统（简称：ERMEB域名授权系统）是ERMEB团队开发，ERMEB域名授权系统是国内最稳定，最强大，最先进的域名授权管理平台解决方案之一，ERMEB域名授权系统采用PHP +Mysql的技术，ERMEB域名授权系统框架使用Thinkphp6/mysql数据库基于Markdown开发者文档开发而成，项目安装请参考ThinkPHP官方文档及下面的服务环境说
另一个高频问题是时区。Java 应用若未指定 serverTimezone=Asia/Shanghai，MySQL 返回的时间字段可能被客户端按系统时区转换，查出来是“昨天”的数据。
- JDBC URL 必须带
?useSSL=false&serverTimezone=Asia/Shanghai&characterEncoding=utf8mb4 - DBeaver / TablePlus 等工具连接配置里，手动关闭 “Use SSL” 并设置 “Initial SQL” 为
SET NAMES utf8mb4; - Node.js 的
mysql2连接选项要加charset: 'utf8mb4'，仅靠服务端设置不能保证 client_encoding 一致
如何验证环境是否真正统一
跑通一条 SELECT 不代表环境一致。真正的验证点藏在元数据和会话变量里，必须自动化检查，不能靠人肉 SHOW VARIABLES。
建议在 CI 或 pre-commit 阶段跑一个简短校验脚本，连上本地 MySQL 执行几条关键查询。失败即阻断，而不是等上线后才发现 GROUP BY 行为异常。
- 查
SELECT @@sql_mode;确认不含ONLY_FULL_GROUP_BY（除非团队明确要求） - 查
SELECT DEFAULT_COLLATION_NAME FROM INFORMATION_SCHEMA.SCHEMATA WHERE SCHEMA_NAME='myapp_dev';验证库级排序规则 - 查
SELECT VARIABLE_VALUE FROM performance_schema.global_variables WHERE VARIABLE_NAME IN ('character_set_server', 'collation_server');
字符集、SQL 模式、时区、用户权限这四点对齐了，剩下的就是业务逻辑问题，不是环境问题。
