musl libc与glibc abi不兼容是根本硬伤，导致mysql官方二进制在alpine中无法运行；可行方案仅有三：使用linuxserver/mysql社区musl镜像、改用原生适配的mariadb，或切换至debian:slim等glibc发行版。
musl libc 与 glibc ABI 不兼容是硬伤
Alpine 默认用 musl libc，而 MySQL 官方二进制（如 mysql-8.0.35-linux-glibc2.17-x86_64.tar.xz）强制链接 glibc。这不是“缺几个库”的问题，而是运行时接口层根本对不上——__libc_start_main、pthread_atfork、clock_gettime 这些函数在 musl 中行为或符号名都不同。哪怕你用 apk add libstdc++ libgcc zlib openssl，也补不齐 ABI 层缺失。
ldd 报错只是表象，exec 失败才是真相
常见现象包括：
-
error while loading shared libraries: libncurses.so.5: cannot open shared object file—— Alpine 中对应的是ncurses-libs=5.9-r4，但装上仍崩，因真正卡点是ld-linux-x86-64.so.2解释器根本不存在 -
exec /usr/bin/mysqld: no such file or directory—— 这不是文件丢了，是内核拒绝加载 glibc 编译的 ELF，因为 interpreter 路径（/lib64/ld-linux-x86-64.so.2）在 Alpine 根本没这回事 - 强行装
glibc-compat后看似启动，但在 SSL 握手、InnoDB 崩溃恢复阶段静默退出，日志里连错误都不留
源码编译也不等于能绕过这个坑
想自己 cmake 编译？必须同时满足：
- 全程用 Alpine 的
build-base工具链，不能混入宿主机的 glibc 头文件（否则编译出的二进制仍隐式依赖 glibc 符号） - 显式指定
-DWITH_SSL=system（用 Alpine 的openssl-dev），否则会拉入 glibc-only 的 BoringSSL 补丁 - 禁用所有依赖 glibc 特有扩展的选项，比如
-DENABLED_LOCAL_INFILE=OFF、-DWITH_NUMA=OFF - 即使成功，生成的
mysqld仍可能在getaddrinfo返回值处理、信号掩码继承等细节上与 musl 行为冲突
真正能落地的只有三条路，没有第四条
别再试 tar -xzf + make install 了。Alpine 上 MySQL 稳定运行的路径只有：
- 用社区 musl 原生镜像：
docker pull ghcr.io/linuxserver/mysql（已预编译、带完整 init 和 logrotate） - 换 MariaDB：
apk add mariadb && mysql_install_db && rc-service mariadb start—— 它从设计就适配 musl - 彻底放弃 Alpine，切到
debian:slim或ubuntu:jammy镜像 —— 如果业务强依赖 MySQL 官方行为且无法接受 MariaDB 兼容性差异
最常被忽略的一点：MySQL 官方压根不测试 musl 环境，它的 CI 只跑 RHEL/CentOS/Ubuntu。所谓“编译通过”，不等于“功能可用”。
