MySQL 服务端运行依赖哪些系统库
MySQL 二进制包或源码编译安装后，启动
mysqld进程时实际依赖的不是“一堆可选插件”，而是几个关键系统级共享库。缺失会导致直接报错退出，比如：
error while loading shared libraries: libaio.so.1: cannot open shared object file。
libaio（Linux AIO 库）：必须。InnoDB 使用异步 I/O，未安装会启动失败；RHEL/CentOS 用
yum install libaio，Ubuntu/Debian 用
apt install libaio1
libnuma（NUMA 控制库）：非强制但强烈建议。多路 CPU 服务器上缺失会导致警告
Warning: ignoring NUMA policy，影响内存分配效率
openssl或
libssl：5.7+ 默认启用 SSL 连接，若禁用
--skip-ssl可绕过，但生产环境不推荐
zlib：压缩协议、备份工具（如
mysqlpump）需要，缺失时对应功能报错
Unknown compression algorithm: zlib
MySQL 客户端连接依赖什么
运行
mysql命令行客户端本身不依赖
mysqld，但它需要自己的运行时链路。常见断连或初始化失败往往卡在这几处：
libtinfo或
libncurses：提供终端控制能力。Alpine Linux 上缺失会报
error: no terminfo database found；需装
ncurses-terminfo-base或软链
/etc/terminfo
libreadline：支持命令历史与行编辑。无此库时客户端能连但无法上下翻历史、
Ctrl+A移动光标失效
libssl：和服务器端一致，若服务端启用了 SSL，客户端未链接对应版本的
libssl会报
SSL connection error: protocol version mismatch
systemd 环境下 MySQL 启动失败的隐藏依赖
用
systemctl start mysqld启动失败，日志里看不到明显库错误？很可能是 systemd 自身的约束被触发：
PrivateTmp=yes（默认开启）：导致
/tmp/mysql.sock被隔离，客户端连不上；应改用
/var/run/mysqld/mysqld.sock并在
my.cnf中显式配置
socket=/var/run/mysqld/mysqld.sock
ProtectHome=yes：若数据目录设在
/home下，启动直接被拒绝；需设为
ProtectHome=read-only或改路径
MemoryLimit/
TasksMax：InnoDB 缓冲池大时可能超限，
systemctl show mysqld | grep Memory可查当前限制
容器中运行 MySQL 的最小依赖集
Docker 或 Kubernetes 场景下，基础镜像越小越容易漏依赖。官方
mysql:8.0用的是 Debian slim，但自定义构建时要注意： Alpine 镜像必须用
mariadb-client替代
mysql-client，因为 Alpine 不兼容 glibc 的 MySQL 客户端二进制 musl libc 环境下不能直接运行官方 MySQL 二进制，必须用
apk add mysql-client（实际是 mariadb 分支）
tzdata包看似无关，但缺失会导致
NOW()返回 UTC 时间且无法通过
SET time_zone切换——因为时区文件不在
/usr/share/zoneinfo真正卡住部署的往往不是大版本兼容性，而是某一个没装的
libaio，或者 systemd 里一个没调的
ProtectHome。这些依赖项不写在文档首页，但出问题时全得一个个对。
