ARM服务器安装MySQL 5.7.44：aarch64预编译tar包全流程详解

简介：面向ARM架构Linux系统的MySQL 5.7.44数据库压缩包，专为国产麒麟V10等平台设计，支持AArch64指令集与64位地址空间，适用于服务器、边缘计算和嵌入式设备。该版本在5.7系列基础上修复了已知漏洞并优化性能，是数据库运维与开发者在ARM设备上部署或升级MySQL的重要选择。

整个资源包约519MB，共2000个文件，其中876个test文件用于回归测试，604个inc头文件与104个h文件辅助开发，234个opt文件供性能调优，49个so动态库和3个a静态库提供运行与编译支持，24个sql脚本、8个cnf配置及文档覆盖初始化、配置与日常维护场景，目录结构清晰便于检索。

已有1919人学习下载。解压安装后可快速获得ARM64 Linux下的完整MySQL运行环境，内置动态与静态连接库、默认配置模板和大量测试用例，有助于验证兼容性、排查故障并加速应用落地，为生产环境迁移和二次开发提供可靠基础。

1. 为什么 ARM 服务器上装 MySQL 5.7 这么折腾：一个 tar.gz 包解决的事

从 x86 迁到 ARM，第一刀往往不是业务代码，而是数据库装不上。MySQL 5.7.44 是 5.7 系列最后一个版本，官方 tar.gz 只发 x86_64 平台；到了鲲鹏、飞腾这类 aarch64 环境里，yum 源找不到匹配包，源码编译又被 cmake 和一堆依赖卡住，一折腾就是一下午。mysql-5.7.44-linux-aarch64.tar.gz 就是为这个场景准备的预编译二进制包——不需要编译、不需要改源码，解压、初始化、起服务就能走。适合手里有 ARM 服务器、业务暂时不能升 MySQL 8.0 的从业者，也适合在 ARM 虚拟机里搭环境做兼容性验证的同学。

2. 认识 mysql-5.7.44-linux-aarch64.tar.gz：包结构、环境检查与解压落地

拿到这个包先别急着解压。同是 ARM 平台，不同发行版之间 glibc 版本、动态库、目录约定差异很大，预编译包能不能跑，取决于宿主机环境是否满足它在编译时记录的链接要求。这一章先把包本身摸清楚，再把环境查透，最后才落盘。

2.1 先看包里是什么：目录结构与核心文件

不解压先看内容，用 tar 的列表模式：

tar -tzf mysql-5.7.44-linux-aarch64.tar.gz | head -40

-t是列出内容，-z表示 gzip 压缩，-f指定文件，head -40只取前 40 行防止刷屏。这个动作除了看结构，还有一个实际价值：如果压缩包在传输中损坏，tar 列出中途会报 CRC 错误或 unexpected EOF，这时候重新下载比解压到一半才发现缺文件省事得多。

正常二进制分发包解压后会得到一个 mysql-5.7.44-linux-aarch64 目录，内部结构如下：

最关键的两个文件是 bin/mysqld 和 bin/mysql：mysqld 是服务端，决定包能不能跑；mysql 是客户端，决定你日常能不能连。share 目录如果被遗漏，启动时会报找不到 errmsg.sys 或时区表加载失败。

再确认一下确实是个 aarch64 二进制，而不是打包时标错名字：

file /usr/local/mysql/bin/mysqld

正常输出会带 "ELF 64-bit LSB executable, ARM aarch64"。如果看到的是 x86-64，那说明包下载错了。

2.2 装之前把三件事查清楚：架构、glibc、动态库

预编译包绑定平台和工具链，aarch64 包只能装在 aarch64 机器上。先跑四条命令：

uname -m cat /etc/os-release ldd --version | head -1

uname -m输出 aarch64 说明系统是 64 位 ARM；os-release 能看出是 CentOS、麒麟还是 Ubuntu，决定后面用 yum 还是 apt；ldd --version第一行是 glibc 版本，MySQL 5.7.44 编译时链接的 glibc 通常要求 2.17 以上，对应 RHEL/CentOS 7、Ubuntu 18.04 及更新的发行版基本都能满足。

然后是动态库依赖。预编译包最怕缺库，这也是 ARM 上启动失败的第一大原因：

ldd bin/mysqld | grep "not found"

有输出就把缺的库补上。MySQL 5.7 在精简系统上最常缺的是 libaio 和 libnuma，包名在不同发行版不一样：

# RHEL / CentOS / 麒麟 yum install -y libaio numactl-libs # Debian / Ubuntu apt install -y libaio1 libnuma1

我的习惯是先 ldd 后安装，缺什么装什么，不把依赖一股脑全装一遍。内网环境装包要审批时，精确的缺依赖列表能省大量沟通成本。

2.3 解压与路径规划：tar 参数说明

我一般把 MySQL 放到 /usr/local 下，用带版本号的目录加软链管理：

tar -zxf mysql-5.7.44-linux-aarch64.tar.gz -C /usr/local cd /usr/local mv mysql-5.7.44-linux-aarch64 mysql-5.7.44 ln -s mysql-5.7.44 mysql

-C指定解压目标目录，省得在下载目录解压再搬一次；改名为不带平台后缀的版本目录，是为了让之后的 mysql.server 脚本和 systemd 单元文件路径稳定；软链指到带版本号的真实目录，以后升级只要换软链，不用动配置。

解压后顺手看一眼权限位。如果包是从 Windows 或 NTFS 挂载目录拷过来的，可执行权限可能丢过：

chmod +x /usr/local/mysql/bin/*

注意：不要把解压出来的目录当成普通资源文件夹。这里面的文件路径本身就是运行时的 basedir 结构，删了任何一个子目录都可能导致二进制找不到库文件。

3. 初始化与启动：五步把一个全新实例跑起来

下载解压只是起点。MySQL 5.7 的 tar 包没有内置数据目录，也不会自动创建系统用户，真要跑起来还要走五步：建用户、建目录、写配置、初始化、起服务。每一步都有坑，下面按顺序讲。

3.1 建系统用户和目录：权限边界一步到位

mysqld 官方手册明确要求不要用 root 跑。第一次图省事直接用 root 启动，大概率会被安全机制直接拒掉；就算侥幸起来，任何 SQL 注入或文件读写漏洞都会放大成整机权限泄露。我一般按这个顺序建：

groupadd mysql useradd -r -g mysql -s /sbin/nologin mysql mkdir -p /data/mysql chown -R mysql:mysql /data/mysql mkdir -p /var/run/mysqld /var/log/mysql chown mysql:mysql /var/run/mysqld /var/log/mysql

useradd -r创建系统用户，-s /sbin/nologin禁止登录，这是安全底线；/data/mysql作为 datadir 与程序目录分离，备份、重装互不影响；/var/run/mysqld放 socket 和 pid 文件——这个目录在系统重启后会被清空，但目录本身必须存在，否则 mysqld 会在创建 socket 那一步失败。

socket 目录的属主经常被忽略。如果/var/run/mysqld属主不是 mysql，启动日志里会看到 Can't create socket file 或 Permission denied。如果系统提示 mysql 用户已存在，跳过 useradd 那两行即可。

3.2 写一个最小可用的 my.cnf

解压包自带 support-files/my-default.cnf，但那个模板路径全都对不上，我不直接用它。在 /etc/my.cnf 写一个最小配置：

[mysqld] user = mysql basedir = /usr/local/mysql datadir = /data/mysql socket = /var/run/mysqld/mysqld.sock pid-file = /var/run/mysqld/mysqld.pid port = 3306 server-id = 1 log-bin = /data/mysql/binlog/mysql-bin expire_logs_days = 7 log-error = /var/log/mysql/error.log # InnoDB innodb_buffer_pool_size = 1G innodb_flush_log_at_trx_commit = 1 [client] socket = /var/run/mysqld/mysqld.sock

逐行说明：basedir指向软链路径，默认找二进制；datadir是数据目录；socket和pid-file必须放进 /var/run/mysqld 并保证属主；log-bin开启 binlog 前要先把 /data/mysql/binlog 目录建好；log-error固定错误日志位置，后面查临时密码和排障都靠它；innodb_buffer_pool_size先给 1G，后面按物理内存调；[client]段的 socket 让 mysql 命令行默认走同一个 socket，不用每次敲 -S 参数。

如果暂时不想开 binlog，把 log-bin 和 expire_logs_days 两行注释掉，server-id 留着不碍事。注意 5.7 里 expire_logs_days 是有效参数，升级到 8.0 时才会被移除。

3.3 初始化数据目录：--initialize-insecure 与 --initialize 怎么选

配置文件就位后建 binlog 目录并初始化：

mkdir -p /data/mysql/binlog chown -R mysql:mysql /data/mysql /usr/local/mysql/bin/mysqld --defaults-file=/etc/my.cnf \ --initialize-insecure --user=mysql

--initialize-insecure会创建一个 root@localhost 空密码账号，首次登录后改密即可；--initialize则把临时密码写到 error log 里，适合生产环境走密码审计流程。我的分工是：测试环境用 insecure，生产环境用--initialize并把临时密码抄进密码本。

初始化成功的标志是命令无输出、退出码为 0，且 error log 里出现 ready for connections 或 Shutdown complete。最常见的失败原因是 datadir 非空——比如之前初始化失败过又没清目录。解决方法是清空数据目录再试：

rm -rf /data/mysql/*

这种做法只适用于「数据可以丢」的场景。如果目录里已经有业务数据，先备份改名，别急着删。

3.4 用 systemd 托管：启动、停服与开机自启

初始化完成后，日常启动我推荐直接用 systemd 托管，而不是 mysqld_safe。服务器重启后自动拉起数据库是刚需，写单元文件一劳永逸：

cat > /etc/systemd/system/mysqld.service <<'EOF' [Unit] Description=MySQL Server 5.7.44 (aarch64) After=network.target [Service] Type=simple User=mysql Group=mysql ExecStart=/usr/local/mysql/bin/mysqld --defaults-file=/etc/my.cnf ExecReload=/bin/kill -HUP $MAINPID LimitNOFILE=65535 Restart=on-failure [Install] WantedBy=multi-user.target EOF systemctl daemon-reload systemctl start mysqld systemctl enable mysqld

单元文件几个关键点：Type=simple表示 ExecStart 直接是前台进程，不要用 forking，那是给 mysqld_safe 准备的；Restart=on-failure让 OOM 或异常退出时自动拉起；LimitNOFILE调高文件描述符上限，避免高并发时报 Too many open files。

启动后验收：

systemctl status mysqld /usr/local/mysql/bin/mysqladmin -S /var/run/mysqld/mysqld.sock -u root ping

第二行输出 mysqld is alive 说明服务正常。然后用空密码进入并设置正式密码：

/usr/local/mysql/bin/mysql -u root -S /var/run/mysqld/mysqld.sock ALTER USER 'root'@'localhost' IDENTIFIED BY 'NewPassword_2024'; flush privileges;

ALTER USER是 5.7 推荐的改密方式，比直接 UPDATE mysql.user 干净，改完不需要重启。再跑一遍 mysql_secure_installation，删掉匿名账号和测试库。

4. 避坑指南：ARM 版 MySQL 5.7 的五个高频故障

下面五条是从实际部署里踩出来的。每条都按「现象 → 原因 → 解决」写，遇到直接照做。

4.1 启动即崩：找不到 libaio.so.1

现象：执行 mysqld 或 systemctl start 后进程秒退，终端或日志显示 error while loading shared libraries: libaio.so.1。

原因：MySQL 5.7 的 InnoDB 依赖 libaio 做异步 I/O，而很多精简安装的 ARM 系统默认没装。这和 x86 上一样会发生，但在 ARM 上概率更高，因为大多数部署起点是干净的 minimal 系统或容器镜像。

解决：apt install -y libaio1或yum install -y libaio，装完再 ldd 确认。注意个别发行版把库装到 /usr/lib，而 MySQL 二进制用 /usr/lib64 的 RUNPATH 查找，这种情况手动建一条软链即可，多数主流发行版 ldd 能直接搜到。

4.2 初始化报错：data directory exists 或目录非空

现象：跑初始化命令立刻退出，报错信息里有 --initialize specified but data directory exists 或 Directory not empty。

原因：初始化强行要求 datadir 为空。多数情况是上一步 mkdir 之后、或者上一次初始化失败，目录里已经写了文件；也有人把 datadir 指到了安装目录下，那目录带了一堆文件当然过不了。

解决：先确认 my.cnf 里 datadir 路径没写错，再清空：

rm -rf /data/mysql/*

如果之前初始化已经成功过，里面生成了系统库和 undo log，这时候不能清空，要备份或改名目录。

4.3 连不上：ERROR 2002 can't connect through socket

现象：mysql -u root 报 ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/tmp/mysql.sock'。

原因：这个报错九成是 socket 路径不一致。客户端默认找 /tmp/mysql.sock，服务端 my.cnf 里却写在 /var/run/mysqld/mysqld.sock，两边对不上。

解决：检查服务端实际 socket 路径，ps 或看 my.cnf；然后统一两边。治本做法是我前面写的——在 my.cnf 的 [client] 段里把 socket 指成服务端路径，此后所有客户端命令都走同一个文件。临时应急用mysql -S /var/run/mysqld/mysqld.sock。

4.4 用 root 直接启动被拒：Fatal error 权限保护

现象：以 root 用户执行 mysqld，启动几秒后 fatal error 退出，日志提示 Please read "Security" section of the manual to find out how to run mysqld as root。

原因：mysqld 出于安全设计拒绝在 root 下直接运行，必须用非 root 账号，或者用 --user 参数显式降权。

解决：统一走 systemd 单元文件里的 User=mysql；手动前台调试时用：

/usr/local/mysql/bin/mysqld --defaults-file=/etc/my.cnf --user=mysql

不要为了图省事把 --user=root 写进配置，那等于把整个数据库权限裸奔。

4.5 起服务报 Permission denied：datadir 和日志目录属主不对

现象：启动后 error log 显示 Permission denied 或 Can't open file，进程退出码 1。常见于从 x86 迁移数据目录，或者建目录时用 root 创建、改属主又漏了子目录。

原因：5.7 对文件属主检查严格，datadir、binlog 目录、日志目录必须全部是 mysql:mysql，任何一个子目录属主是 root，服务就起不来。

解决：对相关目录整体递归修正属主：

chown -R mysql:mysql /data/mysql /var/log/mysql /var/run/mysqld

目录大时 chown 慢一点也正常，别跳过。改完重新 systemctl start mysqld。

5. 从能跑到跑稳：验证与参数微调

服务起来只是第一步，我一般还会做三件事：确认实例信息、核对 NUMA 策略、跑一次轻量压测。

SELECT VERSION(), @@innodb_buffer_pool_size, @@port;

能看到 5.7.44 且 buffer pool 是 1G，说明 my.cnf 生效了；如果 buffer 还是默认的 134M，回查 defaults-file 路径是否被 mysqld 读到，或者配置写进了错误的 ini 段。

ARM 机器和 x86 的一个明显差别是 NUMA。鲲鹏、飞腾多路服务器上，如果 mysqld 的线程跨 node 访问内存，延迟会明显偏高。常见做法是在 systemd 单元文件里给 ExecStart 前置 numactl：

ExecStart=/usr/bin/numactl --interleave=all /usr/local/mysql/bin/mysqld --defaults-file=/etc/my.cnf

numactl 不一定预装，Debian/Ubuntu 需要 apt install numactl。interleave=all 对数据库这类吞吐敏感场景通常比默认策略好，但也有运维专门做绑核，取决于负载特征。

验证安装可以用 MySQL 自带的 mysqlslap，不需要额外装压测工具：

/usr/local/mysql/bin/mysqlslap -u root -p --concurrency=20 \ --iterations=3 --auto-generate-sql \ --auto-generate-sql-load-type=write \ --number-of-queries=1000 --engine=innodb

重点是看三次迭代能不能完整跑完。如果中途报 connection 失败，优先检查 max_connections 和 open-files-limit，这通常不是 ARM 架构的问题，而是资源参数没跟上。

最后提一个坑中坑：升级 MySQL 大版本时，不要把旧 datadir 直接拿给新版本跑。5.7 的字典、数据文件格式和 8.0 不兼容，必须先 mysqldump 全量导出，再导入新实例验证，之后才切流量。我之前有一次图省事复制 datadir，结果一堆表变成 only read 状态，回滚多花了两个晚上。从那以后每次迁移生产库，都强制走一遍全量导出、新实例验证、再切流量的流程，希望帮到你。

本文还有配套的精品资源，点击获取