简介：面向ARM64/aarch64架构Linux、基于glibc 2.28编译的MySQL 5.7.32二进制发行包，专为树莓派、飞腾/鲲鹏等ARM服务器设计，可满足中高级运维与研发人员快速搭建本地数据库服务的需求。压缩包内共14882个文件，除服务端/客户端程序外，opt/inc/cnf分别对应可选组件、头文件与配置实例，so/dat/frm覆盖动态库、数据文件和表定义，另有大量test/result测试套件，整体约510MB，与官方发行版结构一致。该包已有1418人学习下载，适合离线或内网环境直接解压部署。它省去了源码编译与依赖匹配的繁琐过程，开箱即可初始化并运行MySQL；同时借助内置测试集可快速验证部署状态，便于后续调优与维护。无论是个人实验环境还是生产级ARM服务器，均可在此基础上按需裁剪参数，灵活适配不同内存与存储条件，显著降低ARM平台数据库落地的复杂度。
1. 拿到 mysql-5.7.32-linux-glibc-2.28-aarch64.tar.gz，先确认它是给你的
mysql-5.7.32-linux-glibc-2.28-aarch64.tar.gz 这份包我前后在三台 ARM 服务器上装过，第一台最快的 20 分钟运行起来，第一台也是最容易慌张的——报错一个接一个，后来发现都是环境问题，不是包的问题。它本质上是一份免编译的 MySQL 二进制发行包：架构限定 aarch64，运行库要求 glibc 2.28 及以上，解压以后配置好数据目录就能直接用，不需要 gcc、不需要 cmake、不需要在服务器上折腾半小时编译依赖。适合的场景很明确：你手里是一台 ARM 服务器，发行版仓库里的 mysql 要么是 mariadb 要么版本太旧，而你只想安装某个具体版本的 MySQL 5.7。如果你是这类人，这篇就是照着做的工作笔记；如果你只是随便搜到这个名字，那先看第二章，免得解压完才发现基础环境不匹配。
2. 从文件名判断能不能用：glibc 2.28、aarch64 和服务器实际的匹配规则
拿到这份压缩包，第一件该做的事不是解压，是对着文件名做一次环境体检。tar.gz 只是打包格式，真正决定生死的是中间那两段：glibc-2.28 和 aarch64。前者决定你的操作系统运行库够不够新，后者决定你的 CPU 架构对不对。这两点任何一项不满足，后面所有命令都会以各种奇怪的方式失败，而且失败信息还很误导人。
2.1 先别急着解压，看 glibc 版本是否够用
glibc 是 Linux 下最底层的 C 运行库，mysqld 编译时会对它产生符号依赖，这种依赖在运行时才暴露。你系统里的 glibc 版本如果低于 2.28，执行 mysql 的二进制文件时会直接报GLIBC_2.28 not found，这个错误在下一章避坑部分会详细展开。判断方法很简单，在目标服务器上执行：
ldd --version | head -1返回结果的最后一行会显示 glibc 版本号，比如ldd (GNU libc) 2.28。如果低于 2.28，这个包装不上去，不用浪费时间往下走。
我一般还会顺手确认一下系统的发布版本，glibc 和发行版版本号有个粗略的对应关系：常见的 RHEL/CentOS 8、Ubuntu 20.04 以上系统自带 glibc 2.28 或更高，能直接跑；RHEL/CentOS 7 默认 glibc 是 2.17，不行。这里有一个常见误区：有人以为用strings /lib64/libc.so.6 | grep GLIBC_就能看到所有版本，实际上这个命令在部分精简镜像里会因为 libc 路径不同而返回空，不如ldd --version直观。
如果版本确实不够，别试图用软链方式把新版本 libc 替换进系统，这属于最典型的翻车操作，系统基础工具会先崩溃。正确做法是换一个针对低版本 glibc 编译的 MySQL 包，或者直接在目标机器上源码编译，后者耗时但可控。
2.2 aarch64 与 x86_64 包不能互换
aarch64 就是 64 位 ARM 架构，很多云平台的控制台上标注“ARM 架构”或“鲲鹏/飞腾”字样，本质上都是一回事。检查命令：
uname -m输出必须是aarch64，如果是x86_64，这份包直接跳过。MySQL 官方同时发布 x86_64 和 aarch64 两种二进制包，二者不能互换：把 aarch64 包拷到 x86 服务器上，会报Exec format error；反过来也一样。这个错误特别容易让人怀疑是包损坏了，其实只是架构不匹配。
aarch64 架构下还有一个隐藏细节：某些国产 ARM 服务器存在“大小核”或异构 CPU 设计，MySQL 运行时主要依赖主核性能，不影响安装，但如果你的服务器是虚拟机，注意确认 CPU 类型被透传成了 aarch64 而不是模拟的 x86。个别虚拟化平台会模拟 CPU 指令集，导致uname -m显示 aarch64 但运行时出现非法指令，这个属于虚拟化层问题，不在包本身。
2.3 为什么优先选择 tar.gz 而不是 yum/apt 或源码编译
很多 mysql 安装教程第一反应是yum install mysql-server或apt install mysql-server，这条路在 x86 服务器上行得通，在 ARM 服务器上经常卡住。原因主要有三个：发行版仓库里的 mysql 包很多是 mariadb 的改版，行为细节和官方 mysql 不一样；部分仓库里的 mysql 5.7 版本早就停止维护；第三方源在 ARM 架构下的维护质量参差不齐，装完可能缺依赖或启动失败。
源码编译是另一条路，但 MySQL 5.7 源码编译依赖 boost 库、cmake、gcc，在 ARM 服务器上编译一次少则四十分钟多则两个小时，而且编译参数没配好，出来的性能还不如官方预编译包。tar.gz 这种官方二进制包的优势就在这里：Oracle 已经把编译参数、优化选项、依赖关系都处理好了，解压即用，版本可控，升级时替换软链即可。
建议先把包放到一个纯净目录里解压，不要在/root下直接散开。后面每一条命令我都按一套固定目录结构来写，你先跟着这套结构走，生产环境再按自己的规范调整。
3. 部署一条龙：解压、初始化、配置、启动的实操命令
确认架构和 glibc 都没问题后，就可以正式部署了。这一章的步骤我在三台 ARM 服务器上跑的都是同一套，顺序不能乱：先解压建用户、再写配置文件、再初始化数据目录、最后启动设置密码。很多人喜欢先启动再配参数，结果初始化已经按默认配置写入系统表，后面改参数要重来一遍，这个坑后面第 4 章会专门讲。
3.1 解压、软链和用户准备：先把目录结构定死
我一般把 MySQL 安装在/usr/local下，解压后保留版本号目录，再做一个mysql软链指过去。这样升级时只需要切换软链指向，数据目录完全不动，后悔药随时有得吃：
mkdir -p /usr/local tar -xzvf mysql-5.7.32-linux-glibc-2.28-aarch64.tar.gz -C /usr/local ln -s /usr/local/mysql-5.7.32-linux-glibc-2.28-aarch64 /usr/local/mysql解压参数里-x是解包，-z是解 gzip，-v是显示过程，-f指定文件名。生产环境建议去掉-v，因为文件很多，刷屏会影响你观察解压是否出错。解压之后一定要检查软链是否生效：
ls -ld /usr/local/mysql如果输出显示/usr/local/mysql -> /usr/local/mysql-5.7.32-linux-glibc-2.28-aarch64就对了。创建专用用户和数据目录：
useradd -r -s /sbin/nologin mysql mkdir -p /data/mysql chown -R mysql:mysql /data/mysql chown -R mysql:mysql /usr/local/mysql-r表示创建系统账户，-s /sbin/nologin禁止这个账户登录 shell，这是安全基线。MySQL 不允许用 root 直接跑 mysqld（虽然能跑，但会有告警），所以必须用独立账户。数据目录放在/data/mysql而不是/usr/local/mysql/data，我对这种分离有执念——系统盘和数据盘分开，之后磁盘扩容、备份、迁移都方便。如果你服务器只有一块盘，目录放哪里影响不大，但用户和权限这步不能省。
3.2 初始化数据目录：--initialize 与 --initialize-insecure 的选择
初始化这一步是 MySQL 5.7 和 5.6 的最大区别。5.6 直接跑mysql_install_db，5.7 换成了mysqld --initialize。我第一次在 ARM 服务器上装时还不知道这个变化，用了老命令报错才反应过来。初始化前先把配置文件写好，因为部分参数在初始化阶段就要定死，后面改无效。我常用的是--initialize-insecure，这样 root 初始密码为空，方便脚本化后续操作：
/usr/local/mysql/bin/mysqld --initialize-insecure \ --basedir=/usr/local/mysql \ --datadir=/data/mysql \ --user=mysql命令执行完没有输出就是成功，此时查看数据目录和错误日志：
ls /data/mysql tail -30 /data/mysql/mysql-error.log--initialize-insecure的意思是生成一个没有密码的 root 账户，生产环境如果你希望系统自动生成随机密码，就用--initialize，密码会打印到错误日志里，类似A temporary password is generated for root@localhost。--user=mysql指定初始化进程以 mysql 用户身份运行，这点很重要，如果漏掉，数据目录里生成的文件属主是 root，之后 mysqld 用 mysql 用户启动时会因为没权限而报错。
一个常见问题：初始化时报[ERROR] --initialize specified but the data directory has files in it，原因是数据目录不干净。MySQL 初始化只认空目录，里面有残留文件就会拒绝执行。解决方法是把目录清空再跑，但清空前必须确认没有存量数据，否则就是事故。
3.3 一份够用的 my.cnf：参数怎么设、为什么这么设
配置文件我放在/etc/my.cnf，你也可以放/usr/local/mysql/my.cnf，但放在/etc下更符合 Linux 惯例。一份适合大多数 ARM 服务器起步的配置如下：
[mysqld] user = mysql basedir = /usr/local/mysql datadir = /data/mysql port = 3306 socket = /tmp/mysql.sock pid-file = /data/mysql/mysqld.pid log-error = /data/mysql/mysql-error.log character-set-server = utf8mb4 collation-server = utf8mb4_general_ci lower_case_table_names = 1 max_connections = 500 max_connect_errors = 1000 innodb_buffer_pool_size = 512M innodb_flush_log_at_trx_commit = 2 skip-name-resolve参数分组说明一下。路径类参数里basedir指向软链目录，datadir指向数据盘，socket是本地连接用的 Unix socket 文件路径，pid-file和log-error都放在数据目录里，方便日志集中管理。字符集参数把默认编码从 latin1 换成 utf8mb4，这是决定你要不要返工的关键设置，5.7 默认是 latin1，不支持 emoji 和中文生僻字，现在业务基本都是 utf8mb4 起步。lower_case_table_names = 1让表名不区分大小写，这个参数必须在初始化前就配置好，具体原因第 4 章会展开。
性能类参数里innodb_buffer_pool_size是最重要的，建议设为物理内存的 50%-70%。服务器内存 2G 就设 1G，4G 就设 2G，不要贪多，留内存给操作系统缓存和连接线程。innodb_flush_log_at_trx_commit = 2表示每次事务提交只写操作系统缓存不强制刷盘，能明显提升写入性能，代价是数据库异常断电时可能丢失最后 1 秒的事务；如果业务对数据安全要求极高，改成 1。skip-name-resolve跳过 DNS 反解，避免客户端连接时因 DNS 解析超时而变慢，但启用后所有远程连接必须用 IP 而不是主机名。
3.4 启动服务并设置 root 密码：一套连贯的命令链
配置写好后，用 mysqld_safe 启动，这个脚本是官方推荐的前台守护方式，它会自动重启崩溃的 mysqld 并将日志写入指定文件：
/usr/local/mysql/bin/mysqld_safe --defaults-file=/etc/my.cnf &启动后等几秒，检查进程和端口：
ps -ef | grep mysqld | grep -v grep ss -tlnp | grep 3306看到3306端口监听就说明服务起来了。此时用空密码登录：
/usr/local/mysql/bin/mysql -uroot -p提示输入密码时直接回车。登录后立即设置 root 密码并刷新权限：
ALTER USER 'root'@'localhost' IDENTIFIED BY 'YourStrong@Passw0rd'; FLUSH PRIVILEGES;MySQL 5.7 默认开了 validate_password 插件，密码策略要求至少 8 位、包含大小写字母数字和特殊符号，太简单的密码会被拒绝。如果你只是本地测试，可以先降低策略再改密码，但生产环境不要这么干。root 默认只允许本机登录，后续业务接入需要单独创建应用账号，给最小权限：
CREATE USER 'app'@'%' IDENTIFIED BY 'App@Passw0rd'; GRANT ALL PRIVILEGES ON appdb.* TO 'app'@'%'; FLUSH PRIVILEGES;这里'%'代表允许任意 IP 连接，appdb.*表示只授权 appdb 库。生产环境建议把'%'换成具体的业务服务器 IP 段，减少暴露面。
4. 避坑：首次在 ARM 服务器上装 MySQL 最容易翻车的 4 个细节
这一章是我在 ARM 服务器上装 MySQL 的血泪经验汇总，每一条都真实翻过车。现象看着不同，根子上都是环境认知问题。按顺序排查能省下大量时间。
4.1 现象一：启动报 GLIBC_2.28 not found，包被系统拒之门外
现象：执行/usr/local/mysql/bin/mysqld --version直接报错：
/usr/local/mysql/bin/mysqld: /lib64/libc.so.6: version 'GLIBC_2.28' not found (required by /usr/local/mysql/bin/mysqld)原因：目标服务器的 glibc 版本低于 2.28。ARM 服务器经常跑的是精简系统镜像，或者老版本发行版，glibc 停留在 2.17 或 2.27，mysqld 在编译时链入了 2.28 才有的符号，运行时就找不到。
解决：先ldd --version确认版本，确认低于 2.28 后不要尝试替换 libc，正确的出路是换包。去官方下载页找针对低版本 glibc 编译的 MySQL 包，或者在同一台机器上源码编译 MySQL 5.7。ARM 上源码编译耗时比较久，但能彻底避开 glibc 版本问题。如果你的发行版仓库里有 mysql 5.7 且架构匹配，也可以直接用仓库包，只是版本可能不是 5.7.32。
4.2 现象二：初始化时报缺少共享库 libaio.so.1
现象：执行mysqld --initialize-insecure时报错：
error while loading shared libraries: libaio.so.1: cannot open shared object file原因：最小化安装的 ARM 服务器没装 libaio 库。MySQL 在初始化时依赖 libaio 做异步 IO，这个库在完整安装的桌面版系统里默认存在，但服务器精简版经常没有。
解决：先确认缺哪些库：
ldd /usr/local/mysql/bin/mysqld | grep 'not found'然后用发行版包管理器安装。RedHat 系执行yum install -y libaio numactl-libs，Debian 系执行apt install -y libaio1 numactl。装完再跑ldd确认没有not found的项，再继续初始化。这一步还容易踩第二个坑：ARM 系统如果装有 32 位和 64 位两套库，包管理器可能默认装 32 位版本，安装时留意架构输出，确保是 aarch64 的包。
4.3 现象三：lower_case_table_names 改了不生效，线上表名大小写错乱
现象：配置文件里写了lower_case_table_names = 1，但建表语句执行成功，查询时用小写表名却报Table 'xxx' doesn't exist，重启后还是不对。
原因：lower_case_table_names在 MySQL 5.7 里是由初始化阶段写入系统表的，初始化之后修改配置文件不会重新生成。InnoDB 的表名映射在创建数据字典时就定死了，后面改配置只会影响新建的表，已存在的表仍然按原来大小写处理。这个参数同时影响数据目录文件名和 SQL 解析，属于最坑的参数之一。
解决：如果还没初始化，先把lower_case_table_names = 1写进 my.cnf 再做--initialize-insecure。如果已经初始化并且建了业务表，改这个参数没有后悔药，只能备份数据、清空 datadir、重新初始化再导入。所以我在 3.3 里强调先写配置再初始化，顺序反了代价很高。这一条同样适用于 character-set-server 等初始化期参数，业界统称“初始化期参数”，提前想清楚再动手。
4.4 现象四：mysqld 启动失败，只留下一句 The server quit without updating PID file
现象：执行mysqld_safe后进程立即退出，错误日志只有一句：
The server quit without updating PID file (/data/mysql/mysqld.pid)原因：这句话是 mysqld_safe 的封装提示，不是真实错误。真实原因藏在log-error指定的错误日志里，通常是权限不对、pid 文件目录不存在、端口被占用、或者 SELinux 拦截。ARM 服务器上还可能是 mysql 用户对/data/mysql没有写权限，因为初始化时用了 root 执行或者 chown 漏了。
解决：第一步永远先看错误日志：
tail -50 /data/mysql/mysql-error.log常见日志内容对应三种情况：Permission denied说明权限问题，重新执行chown -R mysql:mysql /data/mysql；Can't start server: Bind on TCP/IP port说明 3306 被占用，ss -tlnp | grep 3306查看占用进程；Fatal error: Can't open and lock privilege tables说明表文件属主不对，chown 后重试。SELinux 拦截的表现是日志里没有明显权限报错，但进程就是起不来，此时执行getenforce看状态，如果是 Enforcing，临时用setenforce 0验证，确认是它的问题再针对 mysql 端口和目录配置放行规则。
5. 验证安装并配置 systemd 托管：最后的临门一脚，生产建议升级到 5.7.44
命令行方式启动 mysqld 适合临时验证，服务器重启后不会自动拉起，所以最后一步是写一份 systemd 服务，把 MySQL 纳入系统管理。同时建议你环境稳定后尽快把版本从 5.7.32 升到 5.7.44——那是 5.7 系列的最终维护版本，修掉了 5.7.32 之后暴露的多个安全漏洞和稳定性问题，升级方式我会在下面一并说。
先关闭之前手动启动的 mysqld，注意不要用 kill -9 强杀，避免数据损坏：
/usr/local/mysql/bin/mysqladmin -uroot -p shutdown然后创建 systemd 服务文件/etc/systemd/system/mysqld.service：
[Unit] Description=MySQL 5.7 Server After=network.target [Service] Type=forking User=mysql Group=mysql PIDFile=/data/mysql/mysqld.pid ExecStart=/usr/local/mysql/bin/mysqld_safe --defaults-file=/etc/my.cnf ExecReload=/bin/kill -HUP $MAINPID PrivateTmp=false [Install] WantedBy=multi-user.targetType=forking是因为 mysqld_safe 启动后会自动 fork 出主进程并返回，systemd 通过 PIDFile 跟踪主进程状态。执行：
systemctl daemon-reload systemctl enable --now mysqld systemctl status mysqld看到active (running)就说明托管成功。验证安装是否完整：
/usr/local/mysql/bin/mysql -uroot -p -e "SELECT VERSION(); SHOW VARIABLES LIKE 'character_set_server';"能返回5.7.32和utf8mb4就说明安装和配置都对。最后说升级 5.7.44：先停服务，把新包解压到/usr/local，修改软链指向，再用同一份 my.cnf 启动，数据目录完全不动：
systemctl stop mysqld tar -xzvf mysql-5.7.44-linux-glibc-2.28-aarch64.tar.gz -C /usr/local rm -f /usr/local/mysql ln -s /usr/local/mysql-5.7.44-linux-glibc-2.28-aarch64 /usr/local/mysql chown -R mysql:mysql /usr/local/mysql systemctl start mysqld这个流程能成立的前提就是你安装了 3.1 的软链方案。我见过太多人把 MySQL 直接解压在/usr/local/mysql-5.7.32里裸用，升级时手忙脚乱。养成软链加独立数据目录的习惯，后续所有版本升级都是十分钟内的事。每次装完新的 MySQL 实例，我最后都会做一遍systemctl status、SELECT VERSION()、重启验证这三个动作，确认无误才交付。希望帮到你。
本文还有配套的精品资源，点击获取
