检查 MySQL 运行依赖，核心是确认其底层所需的系统库、运行时环境和基础服务是否就绪。不依赖图形界面或额外中间件，重点在操作系统级兼容性与动态链接库。
检查系统基础依赖（glibc、libaio 等）
MySQL 二进制包（尤其是官方 tar.gz 版）依赖特定版本的系统库。常见依赖包括：
– glibc：MySQL 8.0 通常要求 glibc ≥ 2.17（CentOS 7+/RHEL 7+ 满足，CentOS 6 默认 2.12 不支持）
– libaio：异步 I/O 支持，必须安装（如未装，启动时会报
libaio.so.1: cannot open shared object file）
– numactl（可选但推荐）：提升多 NUMA 节点服务器性能
验证方式：
查看当前 glibc 版本：ldd --version或
getconf GNU_LIBC_VERSION检查 libaio 是否存在：
ldconfig -p | grep libaio；若无，执行
yum install libaio -y（CentOS/RHEL）或
apt install libaio1 -y（Ubuntu/Debian） 确认所有依赖库可被 MySQL 二进制识别：
ldd /path/to/mysqld | grep "not found"，输出为空表示正常
验证动态链接库路径与权限
MySQL 启动时需加载插件（如 validate_password、caching_sha2_password）及存储引擎（InnoDB、MyRocks 等），这些模块为 .so 文件，依赖正确的
LD_LIBRARY_PATH或系统库缓存。
操作建议：
确保plugin_dir配置指向实际存在的目录，且 MySQL 用户有读+执行权限：
ls -l $(mysql -Nse "select @@plugin_dir")若自定义安装路径（如 /opt/mysql），需将对应 lib 目录加入系统库搜索路径：
echo "/opt/mysql/lib" > /etc/ld.so.conf.d/mysql.conf && ldconfig 避免混用不同版本 MySQL 的插件目录，否则可能因 ABI 不兼容导致 mysqld 启动失败
确认内核与文件系统兼容性
MySQL 对内核参数和文件系统特性有隐式要求：
内存与 swap：禁用 swap 可减少 InnoDB 刷脏页延迟（swapoff -a，并注释 /etc/fstab 中 swap 行） 文件系统：推荐 XFS 或 ext4；避免使用 FAT32、NTFS 或网络文件系统（NFS）存放数据目录，否则会触发“Unsupported engine”或崩溃 最大打开文件数：MySQL 需大量文件描述符，检查：
ulimit -n，建议设为 65535+；持久化需配置 /etc/security/limits.conf 和 systemd 的 LimitNOFILE 透明大页（THP）：Linux 默认启用 THP 可能导致 InnoDB 性能下降甚至 hang，建议关闭：
echo never > /sys/kernel/mm/transparent_hugepage/enabled
检查 MySQL 自身依赖组件状态
部分功能模块依赖外部服务或配置，虽非严格“运行依赖”，但缺失会导致对应功能不可用：
systemd 服务管理：使用 mysqld.service 时，确认mysqld_pre_systemd脚本存在且可执行（尤其 Percona Server 或 MariaDB） SELinux/AppArmor：若启用，需放行 MySQL 访问 datadir、socket、端口等资源，否则启动卡在 “Starting MySQL…”；临时排查可用
setenforce 0时间同步服务：NTP 或 chronyd 应运行，避免因系统时间跳变引发 binlog 位点错乱或 GTID 冲突 密码插件依赖：如使用 caching_sha2_password，默认需 OpenSSL 1.0.2+；若手动编译，需确认 -DWITH_SSL=system 或指定路径
依赖检查不是一次性动作，升级 MySQL、更换操作系统或迁移部署时都应重新验证。关键是把“能启动”和“能稳定运行”区分开——前者只看进程是否存在，后者要看日志无警告、关键插件加载成功、连接认证正常、写入不报错。
