企业官网建设流程全解析

很多朋友装机踩坑都是从 CentOS7 安装 MySQL5.7 这一关开始的，x86_64 架构下教程一大把，照着抄基本都能过。但如果你手里的机器是 ARM64——比如鲲鹏 920、飞腾 FT-2000 这类国产 ARM 服务器，或者某些云厂商的 ARM 实例，再或者你是在 x86 电脑上开 QEMU 模拟 ARM 环境折腾——那常规套路往往会栽在半路：官方 Yum 源找不到 aarch64 包、RPM 依赖冲突、启动报 libaio 缺失……这篇文章把我最近在一台 ARM64 CentOS7 上装 MySQL5.7 的完整过程整理出来，包括两条可行路线和一堆排查细节，给后面踩坑的朋友做个参考。

先说结论：CentOS 7 上的 MySQL 5.7 安装最稳的不是 Yum 一键装，而是下载官方 ARM64 通用二进制包手动部署。Yum 方式也能装，但对仓库源、网络和系统状态的要求更高，一旦报错排查起来比想象中费事。两条路我都会讲清楚，你自己按场景选。

1. 为什么 CentOS 7、ARM64、MySQL 5.7 三个词凑一起就这么麻烦

1.1 CentOS 7 的软件源现状

CentOS 7 的生命周期已经很尴尬了，官方停止维护之后，默认的 mirror.centos.org 源基本处于冻结状态，能用，但软件版本永远停在那一年。默认源里的 MySQL 相关包还是 MariaDB 5.5，跟 MySQL 5.7 差了十万八千里。你要装 MySQL 5.7，就得自己去搞第三方源或手工包。

更麻烦的是，ARM64 版本的 CentOS 7 用户量本来就比 x86_64 少很多，很多教程写的时候只在 x86_64 上验证过，根本没在 aarch64 上跑过。你照着 x86_64 的教程敲命令，Yum 源解析出来的 baseurl 是el/7/aarch64，结果仓库里没有这个目录，直接 404，或者仓库里只有 x86_64 的 RPM，报错 "No package mysql-community-server available"。这基本就是架构差异给你上的第一课。

1.2 ARM64 带来的第一道坎：安装包架构不通用

Linux 下安装包是区分架构的，x86_64 的 RPM 不能装在 aarch64 上，二进制更不可能跨架构运行。ARM64 对应的包名后缀是 aarch64，不是 armv7hl，也不是 arm32。这一步很多人直接栽了：下载了一个 arm 的包，结果装上提示 Exec format error，或者bad ELF interpreter。还有些人在网上找了一堆所谓"ARM 版"的 MySQL，其实是树莓派用的 32 位 ARM，和服务器用的 64 位 ARM 完全不是一回事。

这个项目里说的 ARM64，指的就是 aarch64 指令集架构。CentOS 7 官方支持的 ARM64 是基于 AArch64 的，包括鲲鹏、飞腾、华为云擎天、阿里云倚天等平台的 Linux 环境，以及 Apple Silicon 上用 UTM/QEMU 虚拟出来的 CentOS 7 ARM 虚拟机。确认架构最靠谱的命令是uname -m，输出aarch64才对。

1.3 MySQL 5.7 的官方支持边界

MySQL 5.7 官方版本对 ARM 的支持其实一直比较暧昧。简单说，官方提供的 Linux 通用二进制包里有 aarch64 版本（glibc 2.12 那个），但 Yum 仓库里的 RPM 对 ARM64 的覆盖时好时坏。MySQL 8.0 之后对 ARM 的支持明显好了，但 5.7 这个老版本，官方就是把"通用二进制包"当作 ARM 环境的主要发布形态，RPM 仓库更像是个赠品，缺包、断档、404 都是正常的。

所以别指望一条yum install搞定一切。认清这个现实之后，你自然就会明白为什么我要给你两条路：一条是 Yum 源快速路线，一条是手动二进制路线。前者适合网络通畅、能访问官方源的环境，后者适合生产环境、离线环境、还有那些对目录规划有强迫症的场合。

2. 动手前先确认环境：架构、依赖与磁盘规划

2.1 确认系统架构与版本

在跑任何安装命令之前，先把环境信息查清楚。别嫌啰嗦，这一步能帮你避开后面 80% 的玄学问题：

cat /etc/redhat-release uname -m lscpu | grep -E "Architecture|Model name"

uname -m输出必须是aarch64。如果是armv7l那说明是 32 位 ARM，后面所有步骤都不适用。lscpu能看到具体的 CPU 型号，比如 Kunpeng-920 或者 Phytium FT-2000，这决定了你在后面的性能参数调优里大概心里有个数。cat /etc/redhat-release确认系统版本是 7.x，MySQL 5.7 在 CentOS 7.6 以上问题不大，7.0 的老版本可能会有 glibc 或 systemd 兼容问题。

顺便说一下，如果你是在 x86 机器上用 QEMU 模拟 ARM，先确认你的模拟环境能正常启动 CentOS 7 ARM 镜像。之前碰到有人反馈启动时直接报什么 "bad linux arm64 image magic!"，那属于镜像格式和引导配置问题，不是操作系统本身的问题，更不是后面 MySQL 的问题。先把虚拟化层搞利索再说。

2.2 检查 glibc 和基础库

MySQL 5.7 的通用二进制包在发布时会对 glibc 版本有要求。CentOS 7 自带 glibc 2.17，而官方 aarch64 二进制包是用 glibc 2.12 构建的，所以理论上完全兼容。这里不用像网上有些教程说的那样非得升级 glibc，千万别手贱去动 glibc，搞坏了系统基本就只能重装了。

检查一下当前环境：

getconf GNU_LIBC_VERSION rpm -qa | grep glibc

输出 glibc 2.17 就对了，不用做任何操作。接下来要确认另外两个关键的动态库：libaio 和 numactl（libnuma）。MySQL 的 InnoDB 引擎在启动时会调用 libaio 的异步 IO 接口，没有这个库mysqld根本无法启动；numactl 库在 ARM 多路服务器上很常见，MySQL 启动时会去探测 NUMA 节点，找不到虽然也能跑，但会打警告日志。

提前装好它们：

yum install -y libaio numactl-libs ncurses-libs

2.3 规划目录与磁盘挂载

ARM 服务器在云上通常挂载的是云盘，数据目录最好单独放在一个独立挂载点，别和根分区挤在一起。MySQL 的数据文件、binlog、redo log 都是随机读写密集的，根分区一般只有几十 GB，跑几个月就把磁盘撑爆了。而且云盘扩容比本地盘方便得多，后面真要扩展容量，独立挂载点操作起来最省事。

我这里规划的目录结构是：

先用df -h看看你的挂载情况，如果/data已经是一个独立的文件系统最好；如果还没有，把新磁盘用fdisk或parted分区、格式化，再写入/etc/fstab实现开机挂载。这个动作做完再继续，别装到一半发现磁盘不够。

2.4 创建 mysql 用户与数据目录

MySQL 官方建议以独立的mysql用户运行，不要用 root 跑数据库进程。这一步在两种安装方式下都要做：

groupadd mysql useradd -r -g mysql -s /sbin/nologin mysql mkdir -p /data/mysql/data mkdir -p /data/mysql/logs mkdir -p /data/mysql/tmp chown -R mysql:mysql /data/mysql

用-s /sbin/nologin是为了让这个用户不能直接登录 shell，降低被黑后的风险。有些教程里写-s /bin/false，效果类似，但/sbin/nologin在 CentOS 上更规范，遇到 su 切换用户时提示也更友好。

到这里，环境准备就算完成了。接下来的两条路线，你可以像看菜谱一样按需选择。

3. 路线 A：官方 Yum 仓库直接安装（速度最快，但有前提）

3.1 安装 mysql57-community-release 仓库包

MySQL 官方为 CentOS 7 提供了一个仓库配置包，叫mysql57-community-release。通过它可以开启 mysql57-community 这个 Yum 源，然后就能用yum install直接装了。

先安装仓库包：

yum install -y https://repo.mysql.com/mysql57-community-release-el7-11.noarch.rpm

如果网络能通，这步通常几秒钟就完成。装完检查一下仓库文件：

cat /etc/yum.repos.d/mysql-community.repo

你会看到里面有个[mysql57-community]段落，enabled=1表示启用。注意看它的 baseurl，正确写法是类似https://repo.mysql.com/yum/mysql-5.7-community/el/7/aarch64/，这个 aarch64 目录存在与否直接决定了你能不能装成功。

3.2 核对 aarch64 源并执行安装

在装 MySQL 之前，先测试一下这个仓库能不能正常访问：

yum repolist all | grep mysql57 yum --showduplicates list mysql-community-server | grep 5.7

如果看到类似mysql-community-server-5.7.44-1.el7.aarch64的输出，恭喜，这条路能走通。接下来直接：

yum install -y mysql-community-server

安装过程会自动处理依赖，包括 libaio、numactl 这些，不用你手动干预。装完先别急着启动，看一眼初始化日志：

systemctl start mysqld systemctl status mysqld grep 'temporary password' /var/log/mysqld.log

首次启动会自动完成数据目录初始化，并且生成一个临时 root 密码，就在/var/log/mysqld.log里那个temporary password后面。拿到密码后执行mysql -uroot -p，进去第一件事就是改密码，否则 MySQL 会拒绝你执行任何操作。

3.3 这条路的三个典型坑

这条路最丝滑，但并不是每次都这么顺利。我把我踩过的和身边人踩过的写出来：

第一个坑是仓库 404。baseurl里面的$basearch被 Yum 自动替换成aarch64，但官方仓库里如果暂时没有 5.7 的 aarch64 包，就会报 404 或 "No package"。这时候检查一下/var/cache/yum里的缓存，然后yum clean all && yum makecache重试一遍。还是不行，就别死磕 Yum 了，切到路线 B。

第二个坑是 GPG 签名验证失败。CentOS 7 的 curl 版本比较旧，访问官方源下载签名文件的时候偶尔会报证书或 key 导入失败。可以手动导入：

rpm --import https://repo.mysql.com/RPM-GPG-KEY-mysql-2022

如果导入还是失败，使用yum install --nogpgcheck作为临时绕过手段。这只建议在你能确认 RPM 包来源可信的前提下用，生产环境谨慎。

第三个坑是 CentOS 7 官方源失联导致的依赖解析卡死。你执行yum install的时候，系统会先去更新所有启用的源，如果默认的 CentOS Base 源网络不通，安装命令会卡很久甚至直接失败。建议先把国内可用的 Yum 源配置好，也就是常说的"更换国内 yum 源"，把/etc/yum.repos.d/CentOS-Base.repo换成国内镜像源，再执行安装，速度和成功率都会好很多。

4. 路线 B：通用二进制包手动部署（离线环境首选）

4.1 下载正确的 ARM64 Tarball

手动部署的核心是下载官方提供的 "Linux - Generic" 二进制包。这是个压缩包，不需要 RPM 打包的依赖关系，只要满足 glibc、libaio 这些基础条件，解压配置就能跑。

关键点来了：下载的时候一定要选对架构。官方下载页面里，MySQL 5.7 的 Generic Linux 包的命名规则是mysql-5.7.44-linux-glibc2.12-aarch64.tar.gz，注意最后四个字母aarch64，这可不能选错。

cd /usr/local wget https://cdn.mysql.com/archives/mysql-5.7/mysql-5.7.44-linux-glibc2.12-aarch64.tar.gz

如果你的服务器无法直连外网，也可以用本机下载好，再通过 scp/ossutil 传到服务器上。下载完校验一下文件完整性：

md5sum mysql-5.7.44-linux-glibc2.12-aarch64.tar.gz

对比官方页面上的 MD5 值。这一步很重要，因为网上流传的 ARM64 包来源混乱，有一些被改动过的版本，装上之后有各种奇怪问题。

4.2 解压与目录规划

解压并建立软链接，方便后续版本升级时切换：

tar -xzvf mysql-5.7.44-linux-glibc2.12-aarch64.tar.gz mv mysql-5.7.44-linux-glibc2.12-aarch64 mysql ln -s /usr/local/mysql/bin/mysql /usr/bin/mysql ln -s /usr/local/mysql/bin/mysqld /usr/bin/mysqld ln -s /usr/local/mysql/bin/mysqldump /usr/bin/mysqldump

把 bin 下的常用工具软链到/usr/bin，是为了日常执行mysql命令不用每次写全路径，也让一些脚本能直接找到命令。

然后创建 mysql 用户和目录（如果你在第 2.4 节已经做过，这步跳过）：

groupadd mysql useradd -r -g mysql -s /sbin/nologin mysql mkdir -p /data/mysql/data /data/mysql/logs /data/mysql/tmp chown -R mysql:mysql /data/mysql

注意：程序目录/usr/local/mysql本身不用改成 mysql 用户所有，保持 root 所有即可，只有数据目录需要给 mysql 用户读写权限。这个细节很多教程里不写，但养成好习惯能避免权限过度放开放导致的隐患。

4.3 my.cnf 配置：针对 ARM 服务器的参数建议

二进制包默认是没有/etc/my.cnf的，或者只有一个极其简化的版本。我们需要自己写一个。这是整个安装过程中最需要动脑的部分，不同 ARM 服务器配置差异很大。

我的模板：

[mysqld] basedir=/usr/local/mysql datadir=/data/mysql/data socket=/data/mysql/mysql.sock pid-file=/data/mysql/mysqld.pid port=3306 server-id=1 log-bin=mysql-bin binlog_format=row log-error=/data/mysql/logs/error.log slow-query-log=1 slow-query-log-file=/data/mysql/logs/slow.log long_query_time=2 max_connections=500 innodb_buffer_pool_size=512M innodb_log_file_size=256M innodb_flush_method=O_DIRECT character-set-server=utf8mb4 collation-server=utf8mb4_general_ci

几个关键参数重点解释一下：

innodb_buffer_pool_size是 MySQL 内存占用的绝对大头。很多 ARM 服务器起步内存也就是 8G、16G，网上 x86_64 教程喜欢直接写 8G 或 12G，照抄直接内存耗尽。建议初始值取物理内存的 30%-50%，比如 16G 内存先给 4G，后续观察命中率再调整。这里用 512M 属于保守起步值，后续你完全可以根据实际压力调大。

innodb_flush_method=O_DIRECT是为了绕过操作系统 Page Cache，避免双重缓冲。ARM 服务器使用 O_DIRECT 能减少 IO 路径上的 CPU 开销，但前提是你的文件系统支持 direct IO，CentOS 7 默认的 xfs 和 ext4 都支持，可以直接用。

character-set-server=utf8mb4是强烈建议，现在新建数据库表基本都是 utf8mb4，避免后期字符集不一致引发的各种乱码和索引长度问题。

4.4 初始化数据目录

MySQL 5.7 开始，初始化必须通过mysqld --initialize或者mysqld --initialize-insecure来做。以前那种mysql_install_db的老命令在 5.7 里虽然还在，但官方已经标记为废弃，不建议再用。

两种初始化方式的区别：

• --initialize：会生成一个随机临时 root 密码，首登需要临时密码
• --initialize-insecure：root 账号默认无密码，适合内网和自动化场景

生产环境建议用--initialize，密码随机的安全性更好；测试环境为了省事可以用--initialize-insecure。我这里演示的是实际生产部署更常用的方式：

/usr/local/mysql/bin/mysqld --initialize --user=mysql --basedir=/usr/local/mysql --datadir=/data/mysql/data

执行完查看日志：

tail -20 /data/mysql/logs/error.log

日志里会有一行类似[Note] A temporary password is generated for root@localhost: xxxxxxxx的内容，记住这个密码，后面首次登录要用。

如果看到的是[ERROR]开头的行，别慌，按第 5 章的排查链路一步步来。

4.5 首次启动 mysqld_safe

二进制包部署时最常用的启动方式是用mysqld_safe脚本，它会在后台启动 mysqld 并且自动做日志轮转和崩溃重启：

/usr/local/mysql/bin/mysqld_safe --user=mysql &

启动后等一下，确认进程在不在：

ps -ef | grep mysqld tail -20 /data/mysql/logs/error.log

如果看到ready for connections，说明启动成功。然后测试登录：

mysql -uroot -p

输入第 4.4 节拿到的临时密码，回车进去后第一时间改密码：

ALTER USER 'root'@'localhost' IDENTIFIED BY '你的新密码';

MySQL 5.7 默认有密码复杂度校验，密码至少 8 位、包含大小写字母、数字和特殊字符。如果你是在内网测试环境不想搞这么严格，可以先关掉校验插件再设置密码，但生产环境建议保留。

4.6 注册 systemd 服务实现开机自启

mysqld_safe方式启动的进程在系统重启后不会自动拉起，得自己写 systemd 服务。MySQL 自带的support-files/mysql.server是个 shell 脚本，兼容 systemd 的启动方式。

在/usr/lib/systemd/system/mysqld.service写一个服务单元：

[Unit] Description=MySQL 5.7 Community Server After=network.target [Service] Type=forking User=mysql Group=mysql PIDFile=/data/mysql/mysqld.pid ExecStart=/usr/local/mysql/support-files/mysql.server start ExecStop=/usr/local/mysql/support-files/mysql.server stop PrivateTmp=true [Install] WantedBy=multi-user.target

注意Type=forking一定要写对，因为mysql.server start本身会 fork 出 mysqld 进程后立即返回，systemd 用 forking 类型才能正确跟踪子进程。然后执行：

systemctl daemon-reload systemctl enable mysqld systemctl start mysqld systemctl status mysqld

之后服务器的日常启停就都用systemctl start/stop/restart mysqld了，比直接敲mysqld_safe规范得多。

5. 踩坑实录：ARM64 下 MySQL 5.7 的典型故障与排查链路

5.1 libaio/numactl 缺失导致启动失败

这是我见过最频繁的报错，没有之一。现象是执行初始化或启动命令时，直接弹一行错误：

mysqld: error while loading shared libraries: libaio.so.1: cannot open shared object file

原因就是libaio这个动态库没装。CentOS 7 最小化安装时默认不带这个包，MySQL 的 InnoDB 引擎又必须在启动时加载它。解决办法：

yum install -y libaio

如果报的是libnuma.so.1，则是numactl-libs没装：

yum install -y numactl-libs

这类问题的排查思路是：用ldd查看 mysqld 依赖哪些动态库没找到：

ldd /usr/local/mysql/bin/mysqld | grep "not found"

一行命令就能定位所有缺失的库。装完再执行一次，直到ldd不显示任何not found为止。

5.2 初始化时报错：无法创建数据目录文件

ARM 环境里权限问题比 x86_64 下更容易踩，原因是很多 ARM 服务器的/data挂载点创建得比较随意，目录 owner 设置不对。

初始化时常见的报错：

[ERROR] Could not open required defaults file: /etc/my.cnf [ERROR] Fatal error in defaults handling. Program aborted!

或者：

[ERROR] Can't create test file /data/mysql/data/mysql.lower-test

这两个报错本质是同一个问题：运行 mysqld 的系统用户对配置文件或数据目录没有写权限。先看 my.cnf 是否存在、路径是否正确、文件权限是否可读，再看数据目录属主：

ls -ld /data/mysql/data ls -ld /usr/local/mysql

正确状态下，/data/mysql/data的属主应该是mysql:mysql，/usr/local/mysql的属主是root:root，但它的下层文件要允许 mysql 用户读取执行。最快的修复：

chown -R mysql:mysql /data/mysql

还有一种隐蔽情况是/data所在文件系统挂载参数里带了noexec，MySQL 无法在数据目录下创建临时可执行文件。检查挂载参数：

mount | grep /data

如果看到noexec，去掉这个参数重新挂载。这个坑在 ARM 云主机上挺常见的，因为云厂商默认加固时喜欢把非根分区挂上 noexec。

5.3 SELinux 拦截数据目录写入

CentOS 7 默认 SELinux 是 Enforcing 模式。MySQL 的 RPM 安装方式会自带 SELinux 策略，但手动二进制部署方式没有，于是你就会看到进程死活起不来，error.log里也没有明确的权限报错，只有 audit log 在背后抓狂。

排查手段：

setenforce 0 systemctl restart mysqld

如果这样 MySQL 正常启动了，那基本可以断定是 SELinux 在拦截。正规解法是给数据目录打上 MySQL 的 SELinux 标签：

chcon -R -t mysqld_db_t /data/mysql/data chcon -R -t mysqld_log_t /data/mysql/logs

然后恢复 Enforcing 模式再启动，验证一下是否正常。如果打好标签还不行，再查看具体拦截日志：

ausearch -m avc -ts recent

实在搞不定、又不属于强合规环境的话，可以设置 SELinux 为 permissive 模式，注意我只是说这是兜底方案，生产环境最好还是把标签打对。

5.4 小内存机器上的 OOM 与配置陷阱

ARM 服务器起步配置差异极大，从 2G 内存的入门实例到 128G 内存的四路服务器都有。内存小的机器最常见的问题是：innodb_buffer_pool_size 按网上的大内存模板设置，结果mysqld刚启动没几分钟就被 OOM Killer 干掉了。

典型现象是进程突然消失，dmesg或者journalctl -k里能看到oom-kill字样。解决思路很直接，按实际内存量级重新设置参数：

# 2G 内存实例 innodb_buffer_pool_size=256M innodb_log_file_size=64M max_connections=150 # 4G 内存实例 innodb_buffer_pool_size=512M innodb_log_file_size=128M max_connections=300

同时建议开启performance_schema=OFF，这个功能在 5.7 里默认开，但每张表都会消耗额外的内存，小内存机器上收益不高、代价不小。另外table_open_cache从默认的 2000 调到 500 左右，减少文件描述符和内存占用。

调整完这些参数需要重启 MySQL 生效。观察free -m确认内存占用稳定，再继续压测。

5.5 日志排查的先后顺序

很多朋友在 ARM 上装 MySQL 出问题后，第一反应是去搜索引擎复制报错原文，这没问题，但更高效的是先看日志。正确的排查顺序是：

先看 MySQL 错误日志，也就是 my.cnf 里log-error指定的文件。初始化失败的绝大多数原因都会明确写在这里。比如：

[ERROR] InnoDB: Cannot allocate memory for the buffer pool [ERROR] MySQL server has not been started yet, please check the error log

再看系统日志：

journalctl -u mysqld -n 50 dmesg | tail -20

最后才去考虑搜索引擎。日志给出的错误信息远比你在网上盲猜靠谱。这个习惯养成了，后面运维 MySQL 遇到问题能少走很多弯路。

6. 装完不是结束：安全加固、自启与连接验证

6.1 mysql_secure_installation 实操

无论是 Yum 路线还是二进制路线，装完后第一件事都是跑一遍安全初始化脚本：

mysql_secure_installation

这个脚本交互式地引导你做五件事：设置 root 密码、删除匿名用户、禁止 root 远程登录、删除 test 数据库、重载权限表。生产环境建议全选 Y。

可能出现的一个问题是二进制包部署时mysql_secure_installation所在目录不在 PATH 里，需要写全路径执行：

/usr/local/mysql/bin/mysql_secure_installation

脚本会要求先输入 root 密码。这里要注意，如果之前设置过密码强度策略，新密码也得满足同样要求。

6.2 创建业务账号与授权

root 账号只保留本地登录就够了，日常业务不要用 root。创建一个应用账号：

CREATE USER 'app_user'@'%' IDENTIFIED BY 'App_User_123!'; GRANT ALL PRIVILEGES ON app_db.* TO 'app_user'@'%'; FLUSH PRIVILEGES;

'%'表示允许任意主机连接，如果业务服务器 IP 固定，建议写死具体 IP，比如'10.0.0.10'。权限粒度越小越好，只需要 SELECT/INSERT/UPDATE/DELETE 就给这些，不要图省事直接给 ALL。

ARM 服务器上跑业务数据库还有一个值得注意的点：如果应用在同一台机器上，建议连接数据库时走 socket 而不是 TCP，省掉一次网络栈开销，延迟和 CPU 占用都会低一些。

6.3 防火墙与端口策略

CentOS 7 默认的防火墙是 firewalld。MySQL 端口 3306 默认不开放，外部机器连不上是正常现象。按需放行：

firewall-cmd --permanent --add-port=3306/tcp firewall-cmd --reload

如果数据库只给内网访问，建议指定来源网段而不是直接放通所有来源：

firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="192.168.1.0/24" port protocol="tcp" port="3306" accept' firewall-cmd --reload

另外确认my.cnf里的bind-address设置。默认注释掉相当于监听所有网卡，如果只想本机访问，改成bind-address=127.0.0.1；如果要给其他机器访问，就得保持监听外部网卡并配合防火墙规则一起用。

6.4 连接测试与基本性能确认

全部搞定后，做一轮基础验证：

mysql -h 127.0.0.1 -P 3306 -uapp_user -p -e "SELECT VERSION();" mysql -h <服务器IP> -P 3306 -uapp_user -p -e "SHOW VARIABLES LIKE 'innodb_buffer_pool_size';"

然后跑一个简单的压测确认 ARM 环境下性能没有明显异常：

sysbench --test=oltp --db-driver=mysql --mysql-host=127.0.0.1 --mysql-user=app_user --mysql-password=xxx --oltp-table-size=1000000 prepare sysbench --test=oltp --db-driver=mysql --mysql-host=127.0.0.1 --mysql-user=app_user --mysql-password=xxx --oltp-table-size=1000000 --num-threads=8 --max-time=60 run

ARM 服务器的单核性能比 x86 同代产品弱一些，这是硬件本身的特点，只要压测结果符合你业务的预期就没问题。看到 TPS 数字和延迟都稳定，说明这台 MySQL 已经可以正式接活了。

写到最后再分享一点个人体会。我在 ARM64 CentOS7 上装 MySQL5.7 这个组合，前前后后试过 Yum、二进制包、甚至 Docker 容器几种方式。Docker 的话官方mysql:5.7镜像是有 arm64 变体的，跑起来确实省事，但如果你的场景是物理机直装、要求目录可控、还要做和现有监控体系对接，那手工二进制部署依然是绕不开的必修课。Yum 路线适合一次性快速部署的环境，二进制路线适合生产环境、离线内网、以及对部署过程有审计要求的人。如果你时间充裕，建议两条路都在测试机跑一遍，亲身体验一下各自的坑在哪，后面真正上生产的时候就会淡定很多。这里面的核心思路其实很简单：搞清架构、看准日志、控制权限、小内存环境下保守配置，做到这四点，ARM64 上的 MySQL 5.7 就没有想象中那么难缠。