直接用 mysql:alpine 仍可能超重，因其默认包含完整客户端工具、测试套件残留、多语言字符集文件及未清理的 apk 缓存，实测体积达 70–90mb。
为什么直接用 mysql:alpine 仍可能超重？
官方 mysql:alpine 镜像虽比 Debian 版轻，但默认包含完整客户端工具（mysql、mysqldump、mysqladmin）、测试套件残留、多语言字符集文件和未清理的 apk 缓存。实测镜像体积常达 70–90MB，远高于「极简」目标（
apk add --no-cache --virtual 必须成对出现
Alpine 的包管理行为和 Debian 不同：不加 --no-cache 会把索引和 .apk 包留在 /var/cache/apk/，悄悄吃掉 3–5MB；不配合 --virtual 分组则无法一键清理构建依赖。错误写法如分两行 RUN apk add --no-cache gcc + RUN apk del gcc 会导致中间层残留，体积不降反升。
- 正确模式必须是单条
RUN指令内完成安装 → 使用 → 删除 - 构建期依赖（如编译工具链）用
--virtual .build-deps命名，后续apk del .build-deps才能真正清空 - 运行时仅保留
mysql-client（非完整mysql包），它只含mysql命令，不含mysqldump等冗余二进制
多阶段构建中如何安全复制 MySQL 二进制？
直接 COPY 官方 tar 包解压后的整个目录，容易混入 /usr/share/mysql 下的字符集、示例配置、文档等非运行必需内容。更可控的做法是显式声明最小依赖路径：
- 只 COPY
/usr/bin/mysqld、/usr/bin/mysql、/usr/lib/mysql/plugin/（InnoDB 引擎必需） - 跳过
/usr/share/全部子目录（含mysql-test、doc、charsets中除latin1和utf8mb4外的所有目录） - 启动脚本里用
--skip-grant-tables或--initialize-insecure避免首次启动依赖 Perl（标准 Alpine 不含 Perl）
固定 Alpine 小版本并禁用 tzdata 是体积控制关键点
用 alpine:latest 或 alpine:3 会导致构建不可复现：上游可能悄悄升级 musl libc 或新增默认包。实测 alpine:3.20 比 3.18 多出约 1.2MB 的 tzdata 包（MySQL 本身不依赖时区数据，除非显式配置 default-time-zone）。
- 必须写死小版本：
FROM alpine:3.20，而非alpine:3 - 在 RUN 指令开头加
apk del tzdata（如果已装），或启动前用ENV TZ=UTC避免加载 - 检查最终镜像是否含
/usr/share/zoneinfo/—— 存在即说明未清理干净
极简不是删到不能跑，而是删掉所有「启动后第一次 SQL 查询之前」不需要的东西。最容易被忽略的是字符集文件和插件目录里的非 InnoDB 引擎（如 myisam、archive），它们默认随二进制一起安装，但只要配置里明确禁用，就该从镜像中物理移除。
