mysql服务端启动必须依赖libaio，强烈建议libnuma，5.7+需openssl/libssl（可跳过但不推荐），zlib用于压缩功能；客户端依赖libtinfo/ncurses、libreadline、libssl；systemd下需注意privatetmp、protecthome等配置；容器中alpine需用musl兼容的mariadb-client及tzdata。
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。这些依赖项不写在文档首页，但出问题时全得一个个对。 
