简介：这是为 ARM 64 位架构（AArch64）编译的 MySQL 5.7.32 二进制发行包，基于 glibc 2.28，面向树莓派、ARM 服务器等场景下的开发与运维人员，免编译、可离线安装部署，适合缺少现成软件源或需要离线交付的环境。压缩包共 14882 个文件、约 510.16MB，包含大量测试用例与结果集、配置模板、头文件、动态库及初始化脚本，其中 test/result 目录便于回归验证，opt/inc 与 cnf 可支撑依赖分析和二次定制，so 动态库以及 mysql_install_db、mysql_secure_installation 等工具脚本则提供核心运行与部署能力。已有 1418 人学习，适合需要快速搭建 ARM 版 MySQL 环境、进行性能评估或离线上线的用户。资源内还提供 binlog、GTID、复制等测试场景样例，配合初始化、安全加固与管理流程，可帮助理解主从同步、事务日志等核心机制；同时包含 InnoDB 改进、JSON 支持和 Performance Schema 等特性，便于在此基础上搭建高可用或嵌入式数据服务，也为国产 ARM 平台迁移参考。
1. 这个文件名里藏着什么：版本、架构、glibc 门槛一次看清
mysql-5.7.32-linux-glibc-2.28-aarch64.tar.gz 这个文件名看着长，拆开实际是四块信息：版本号是 5.7.32，运行平台是 Linux，动态库要求 glibc 不低于 2.28，CPU 架构是 aarch64。你大概率是遇到这样一种情况：手头有一台 ARM 64 位服务器，包管理器源里要么没有官方 MySQL 5.7，要么默认版本和线上环境对不上，只能自己下载官方编译好的二进制包来部署。这篇笔记就把整个过程走一遍，从确认这台机器能不能跑这个包开始，到解压、初始化、启动、做成服务，最后把我在 aarch64 上部署 5.7 时踩过的坑逐条列出来，新手能照着做，熟手可以直接跳到第 5 章看问题清单。
2. 部署前先回答三个问题：aarch64、glibc 2.28、依赖库
2.1 先确认架构：uname、lscpu 与 /proc/cpuinfo 交叉验证
动手部署之前，先给这台服务器做个体检。很多人拿到 tar 包就直接解压，结果 ./bin/mysqld 一跑就崩，回头看才发现架构根本不是 aarch64。我一般先执行这条命令：
uname -m正常情况下，64 位 ARM 服务器会输出 aarch64，x86 服务器会输出 x86_64，32 位 ARM 老设备输出 armv7l。这个输出直接决定安装包选型。这里有个容易看走眼的地方：某些系统里 arch 命令输出的是 arm64，而 uname -m 输出 aarch64。两者其实是同一个架构的不同叫法，可以放心用；反过来，如果输出里带 32，比如 armv7l，那就不能用这个包。
除了 uname，还可以用下面的方式交叉确认：
# lscpu 输出里看架构 lscpu | grep Architecture # cpuinfo 里看处理器列表 grep -c processor /proc/cpuinfolscpu 的 Architecture 字段写 aarch64，CPU op-mode(s) 写 32-bit, 64-bit，基本可以确认。这里有一个在 ARM 服务器上容易被忽略的点：很多 ARM 服务器是虚拟化出来的，/proc/cpuinfo 和宿主机一样暴露 aarch64，但你并不确定宿主机是否完整支持 ARMv8-A 指令集。如果虚拟化层对部分指令做了降级处理，MySQL 启动时可能出现指令集相关的随机崩溃。这种问题属于玄学范畴，排查起来最耗时间。建议部署前先跑一小段 CPU 压测程序，确认指令集稳定后再投入生产。
还要顺带提一下磁盘空间。aarch64 服务器常见配置是系统盘和数据盘分开，解压前用 df -h 看 /usr/local 和 /data 的剩余空间，避免装到一半盘满。MySQL 5.7.32 的二进制目录解压后大约占 1 GB 左右，数据目录按业务量预留，只多不少。
2.2 glibc 版本检查：为什么二进制包会挑系统底子
版本兼容性的核心是 glibc。文件名里的 glibc-2.28 表示这个二进制在 glibc 2.28 环境下编译，运行时要求系统的 glibc 版本不低于 2.28。为什么会有这个要求？因为动态链接器加载可执行文件时，会校验每个符号引用的版本号。MySQL 5.7 的 glibc 2.28 包使用了一些新版本 glibc 才引入的符号，老系统里没有这些符号，链接器直接拒绝加载。
先查当前系统 glibc 版本：
ldd --version第一行会输出类似 ldd (GNU libc) 2.35 这样的内容。如果你的系统 glibc 是 2.17、2.19 这类老版本，这个包就跑不了。想再看得细一点，可以用 readelf 列出二进制对 glibc 的符号需求：
readelf -V /usr/local/mysql/bin/mysqld | grep -E "GLIBC_2\.[0-9]+" | sort -u | tail -n 10输出会列出所有需要的 GLIBC 版本符号，比如 GLIBC_2.28、GLIBC_2.17、GLIBC_2.18。这里要提醒一个细节：readelf 输出里出现 GLIBC_2.28，不代表系统必须精确到 2.28，而是编译时用到的最高的那个版本符号才是硬门槛。直接看 ldd --version 的版本号，足够做判断了。
在 aarch64 服务器上，常见情况是发行版比较新，glibc 版本大多高于 2.28，可以直接用这个包。如果遇到老系统，常规做法是两条：升级系统到新高版本，或者改用源码编译安装。但源码编译出来的二进制同样受本机 glibc 影响，想彻底绕开只能静态编译，而 MySQL 官方不提供静态编译版本。所以最省力的判断标准是：ldd --version 输出大于 2.28，就用官方包；低于这个版本，先别折腾，考虑换系统或升级。
2.3 依赖库三件套：libaio、libnuma、ncurses 缺一不可
glibc 只是底线。MySQL 5.7 的二进制动态链接了一批第三方库，最常见的三个依赖是 libaio、libnuma 和 ncurses。libaio 提供异步 I/O 接口，InnoDB 默认用它做预读和刷盘；libnuma 管非均匀内存访问策略，在 aarch64 多路服务器上配置不当会造成内存绑定异常；ncurses 是终端库，mysql 命令行客户端交互界面需要它。这三个库平时不起眼，缺任何一个都能让服务起不来。
检查方式很直接：
# 在解压后的 MySQL 目录里执行，结果无输出说明依赖齐全 cd /usr/local/mysql ldd ./bin/mysqld | grep "not found"如果输出 libaio.so.1 => not found 之类的行，就说明缺库。按发行版把依赖装上：
# Debian/Ubuntu 系 apt-get update apt-get install -y libaio1 libnuma1 libncurses5 # RHEL/CentOS 系 yum install -y libaio numactl-libs ncurses-libs装完重新跑一次 ldd，确认所有依赖都解析到实际文件后继续。这里有个容易踩的坑：ncurses5 和 ncurses6 在一些发行版上会互相覆盖。MySQL 5.7 客户端对 ncurses5 兼容更好，装了 6 遇到界面乱码，可以用 update-alternatives 切换回去。另外，某些精简系统镜像连 tar 和 wget 都没有，先补齐基础工具再下载安装包，否则会卡在最前面。
依赖检查到这里，还有一个经常被拿来对比的方案：为什么不用 docker 镜像直接跑？在 x86 服务器上 docker 安装 mysql 确实省事，但不少 ARM 服务器的 docker 镜像源不完整，内核模块对 aarch64 的支持也参差不齐，部分设备上会出现镜像启动后进程直接退出。docker 方案适合已经有容器管理体系的团队，否则在裸系统上先装 docker 再排 mysql 的坑，反而多绕一圈。手动部署官方二进制包，是最直接、也最不容易被环境问理会牵着走的方案。
3. 解压、建用户、初始化：把 MySQL 5.7 落到磁盘上
3.1 解压与目录规划：二进制、数据、日志三层分离
包下载完之后，先解压。整个目录规划我建议这样：二进制放 /usr/local/mysql，数据放 /data/mysql，日志放 /var/log/mysql，socket 放 /tmp/mysql.sock。不要图省事全塞一个目录，原因是数据盘和系统盘分开，能避免数据库写满拖垮系统；日志单独放便于日志轮转和排查。
# 解压到 /usr/local tar -xzf 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 # 创建数据目录和日志目录 mkdir -p /data/mysql mkdir -p /var/log/mysql参数说明：
- -C 指定解压目标目录，不要漏，否则解压出来的目录会落在当前 shell 的工作目录下。
- ln -s 做软链接的核心目的：未来升级时把 link 切到新版本目录，不用改 path 和 systemd 配置，这是后期维护最省事的手法。
- 数据目录和日志目录分开，aarch64 服务器如果配了 NVMe 高速盘，把数据目录放到高速存储上收益最明显。
一个小提醒：确认一下数据目录挂载的分区是不是有 noexec 或 nosuid 挂载选项。用 mount 命令查看，如果 /data 带 noexec，MySQL 初始化时无法在数据目录执行临时程序，会报权限类错误。这种情况要把数据目录换到不带 noexec 的分区，或者调整挂载参数。
3.2 创建专用运行用户：mysql 用户、属主与最小权限
MySQL 官方强烈建议不要用 root 跑 mysqld。原因很简单：mysqld 一旦出现安全漏洞，攻击者拿到的是一个 root 权限的 shell。正确的做法是创建专用系统用户，然后分配目录权限。
# 创建系统用户，不登录、无 Home 目录 useradd -r -s /sbin/nologin mysql # 给数据目录和日志目录设置属主属组 chown -R mysql:mysql /data/mysql chown -R mysql:mysql /var/log/mysql # 二进制目录属主保持 root，属组改成 mysql chown -R root:mysql /usr/local/mysql # 限制普通用户进入数据目录 chmod 750 /data/mysql说明：
- useradd -r 创建系统账户，UID 落在系统区间，不给登录 shell，符合最小权限原则。
- 数据目录属主 mysql，让 mysqld 进程能正常读写；二进制目录保持 root 属主，普通用户只能通过 mysql 属组的读权限访问。
- chmod 750 限制普通用户进入数据目录，防止数据文件被误读或误删。
这里补充一个常见的纠结点：要不要配置 PATH 环境变量。我一般建议不要在 /etc/profile 里写 MySQL 的 PATH，而是用全路径调用 mysql 和 mysqld。原因是 PATH 污染会让系统自带的 mysql 客户端和这个新装的打架，排查起来非常费劲。后面所有命令我都用全路径，这样任何一台机器上都能凑效。
3.3 初始化数据目录：mysqld --initialize 是 5.7 的必经一步
MySQL 5.7 之后，初始化数据目录的方式变了。5.6 及更早用 mysql_install_db 脚本，5.7 起官方推荐用 mysqld --initialize。这一步会往数据目录写入系统表、权限表、undo 日志和 binlog 初始文件，同时生成一个临时 root 密码。这一步做错，后面无论如何都启动不了。
cd /usr/local/mysql # 指定配置与目录，完成初始化 ./bin/mysqld --initialize \ --user=mysql \ --basedir=/usr/local/mysql \ --datadir=/data/mysql \ --log-error=/var/log/mysql/error.log参数说明：
- --user=mysql 让初始化进程以 mysql 身份运行，和上一步创建的账户对应。
- --basedir 指向二进制目录，--datadir 指向数据目录，两个路径都建议写绝对路径。
- --log-error 指定错误日志位置，后面的排障信息都从这里看。
- 初始化成功后，临时密码会出现在 error.log 里，先记下来。忘了这个密码，登录会卡在第一步。
初始化完成的标准是目录里出现关键文件：
ls -l /data/mysql | head -n 20 # 正常会出现 auto.cnf、ib_buffer_pool、ibdata1、undo_001 等文件有这些文件说明初始化基本成功。如果初始化报错，最常出现两类：一类是 data directory exists，说明目录里已有文件；另一类是 error while loading shared libraries，说明第 2 章的依赖库没配齐。这两类问题，第 5 章会逐个拆解。
3.4 写一份能直接用的 my.cnf：关键参数与合理取值
my.cnf 是 MySQL 的启动配置，默认读取顺序是 /etc/my.cnf、/etc/mysql/my.cnf、~/.my.cnf。部署时建议统一放在 /etc/my.cnf，避免多份配置互相覆盖。下面是一份适合 8 GB 内存的 aarch64 服务器起步配置，各个关键路径都明确指定。
[client] port = 3306 socket = /tmp/mysql.sock [mysqld] user = mysql port = 3306 socket = /tmp/mysql.sock basedir = /usr/local/mysql datadir = /data/mysql log-error = /var/log/mysql/error.log pid-file = /var/run/mysql/mysql.pid character-set-server = utf8mb4 collation-server = utf8mb4_general_ci # InnoDB 缓冲池，按物理内存 50%-70% 设置，8GB 机器给 4GB innodb_buffer_pool_size = 4G # 每张表独立表空间，便于空间回收 innodb_file_per_table = 1 # 日志文件大小，过大恢复慢，过小频繁刷盘 innodb_log_file_size = 256M # 二进制日志，主从复制和时间点恢复的基础 server-id = 1 log-bin = /data/mysql/binlog/mysql-bin expire_logs_days = 7 # 连接数上限 max_connections = 500 # 时区，避免出现 8 小时偏差 default-time-zone = '+08:00'参数说明：
- utf8mb4 是 5.7 上推荐使用的字符集，兼容 emoji 和更多 Unicode 字符；排序规则 utf8mb4_general_ci 应对大多数业务足够。
- innodb_buffer_pool_size 是 5.7 性能最关键的参数，建议按物理内存 50% 到 70% 设置。在 ARM 服务器上尤其注意，别把内存全部给 MySQL，系统本身和堆外内存也要留余量。
- log-bin 开启二进制日志，是做主从复制和时间点恢复的基础。单实例且不需要恢复的话，可以注释掉。
- expire_logs_days = 7 控制 binlog 保留 7 天，避免磁盘被 binlog 占满。
- default-time-zone 按实际时区调整。不设置的话，某些驱动会按 JVM 或系统时区换算，容易出现经典的 8 小时偏差。
配置写完后，先用命令校验语法：
/usr/local/mysql/bin/mysqld --basedir=/usr/local/mysql --datadir=/data/mysql --validate-config没有输出说明配置文件基本可用。注意 --validate-config 只校验语法和参数取值，不会校验路径是否存在，所以路径类问题还得靠启动时的错误日志排查。
4. 启动 MySQL：先验证能跑，再做成 systemd 服务
4.1 mysqld_safe 手动启动：进程、端口、ping 三层验证
配置写完后，不要急着配 systemd。先用 mysqld_safe 手动拉起来，确认初始化、配置、权限都正确，再谈开机自启。直接执行：
/usr/local/mysql/bin/mysqld_safe --defaults-file=/etc/my.cnf &注意两点：mysqld_safe 是官方提供的守护式启动脚本，它会自动检测 mysqld 状态，异常退出时会尝试重新拉起。加 & 放到后台，日志写到 my.cnf 指定的 error log，终端里看不到输出是正常的，去 /var/log/mysql/error.log 看。
验证启动是否成功的标准动作：
# 查看进程 ps -ef | grep mysqld | grep -v grep # 查看端口监听 ss -tnlp | grep 3306 # 用 mysqladmin ping 检测服务状态 /usr/local/mysql/bin/mysqladmin --socket=/tmp/mysql.sock ping如果进程在、端口在、ping 返回 mysqld is alive，启动成功。这一步是整个部署中最容易出问题的阶段，日志是关键。任何启动报错，先看日志：
tail -n 50 /var/log/mysql/error.log常见错误包括权限不对、socket 目录不存在、pid 目录不存在，这些坑在第 5 章里逐个讲。如果 ping 报错，先确认 socket 路径和 my.cnf 一致，再去查 /tmp/mysql.sock 文件是否存在。
4.2 systemd 服务化：配置文件、开机自启与几个必改参数
手动启动成功后，开始配置 systemd。在 aarch64 服务器上，systemd 已经是主流 init 系统。创建一个服务文件：
cat > /etc/systemd/system/mysql.service << 'EOF' [Unit] Description=MySQL 5.7.32 on aarch64 After=network.target [Service] Type=forking User=mysql Group=mysql PIDFile=/var/run/mysql/mysql.pid ExecStart=/usr/local/mysql/bin/mysqld_safe --defaults-file=/etc/my.cnf ExecReload=/bin/kill -HUP PrivateTmp=false [Install] WantedBy=multi-user.target EOF # 重新加载 systemd 配置 systemctl daemon-reload # 启动服务 systemctl start mysql # 设置开机自启 systemctl enable mysql参数说明：
- Type=forking：mysqld_safe 先 fork 出子进程再返回，systemd 用 PIDFile 跟踪实际服务进程，所以 pid-file 路径必须和 my.cnf 里配置一致。
- User/Group 要写成 mysql，不能写 root，否则和初始化时的属主不一致，启动会报目录权限错误。
- PrivateTmp=false 在这里必须显式写。如果 PrivateTmp=true，service 里的 /tmp 会被私有化，而 my.cnf 里 socket 路径写的是 /tmp/mysql.sock，客户端用这个 socket 永远连不上，这是个非常隐蔽的坑。
- 启动完成后执行 systemctl status mysql，确认 Active 状态。
这里有一个对新手特别迷惑的地方：systemctl start mysql 之后，立即执行 status 显示 active（running），但过几秒再看变成 failed。原因是 mysqld 进程启动过程中崩溃，systemd 认为服务退出了。遇到这种情况，不要去改 systemd 配置，优先看错误日志，问题几乎都在 MySQL 侧。
4.3 首次登录改密码：临时密码、认证插件与远程账号
服务起来之后，用初始化阶段生成的临时密码登录，然后立即改密码。命令如下：
# 读取临时密码 grep "temporary password" /var/log/mysql/error.log # 用临时密码登录 /usr/local/mysql/bin/mysql -uroot -p --socket=/tmp/mysql.sock # 登录后执行密码修改 ALTER USER 'root'@'localhost' IDENTIFIED BY 'NewStrongPassword@2024';修改完密码后，顺手做几个检查：
SHOW VARIABLES LIKE 'version'; SHOW VARIABLES LIKE 'version_comment'; SHOW VARIABLES LIKE 'default_authentication_plugin';输出里 version 应该是 5.7.32，version_comment 会带 Community Server 字样，default_authentication_plugin 在 5.7 上是 mysql_native_password。这里说明一下：MySQL 5.7 的默认认证插件是 mysql_native_password，客户端兼容性比 8.0 的 caching_sha2_password 省心，但老版本的驱动连接时依然要注意密码规则。
如果业务需要远程访问，不要给 root 直接开远程权限，创建一个独立账号：
CREATE USER 'dev'@'192.168.%' IDENTIFIED BY 'DevPassword@2024'; GRANT ALL PRIVILEGES ON *.* TO 'dev'@'192.168.%'; FLUSH PRIVILEGES;账号授权完成后，建议从另一台机器用一个简单的查询验证连通性：
mysql -udev -p -h 192.168.x.x -P 3306 -e "SELECT 1"能返回 1 说明网络、账号、端口都通了。到这里，MySQL 5.7.32 的部署已经基本完成，剩下的工作是把可能踩到的坑提前摸清楚，以及做一轮性能基线验证。
5. 避坑排查：aarch64 上部署 MySQL 5.7 的 5 个实际问题
5.1 libaio.so.1 找不到导致启动崩溃
现象：第一次执行 mysqld_safe 或直接跑 mysqld，错误日志或终端直接报：
libaio.so.1: cannot open shared object file: No such file or directory原因：MySQL 5.7 的 InnoDB 存储引擎默认调用异步 I/O 接口，依赖 libaio 运行库。aarch64 服务器如果用的是精简系统镜像，默认不装任何额外运行库，这是最常见的翻车点。
解决：按第 2 章的命令把 libaio 装上。装完用 ldd 复查：
ldd /usr/local/mysql/bin/mysqld | grep aio输出 libaio.so.1 => /lib/aarch64-linux-gnu/libaio.so.1 说明已经链接上。另一种情况是库文件存在但权限不对，用 ls -l 看下 /lib/aarch64-linux-gnu/libaio.so.1 是否对所有用户可读，mysqld 以 mysql 用户运行，读不到也会报错。
5.2 初始化报 data directory exists，目录清理与路径规划
现象：执行 mysqld --initialize 时立即报错：
[ERROR] --initialize specified but data directory exists原因：数据目录不是空目录。两类情况最常遇到：一是之前初始化过又中途失败，目录里残留半成品文件；二是目录本身就是挂载点，挂载点自带 lost+found 目录，MySQL 认为目录非空。
解决：先看目录里到底有什么：
ls -la /data/mysql如果残留的是初始化半成品，确认无用后备份再清空；如果是 lost+found 这种系统目录，就换一个子目录做 datadir，比如 /data/mysql/data。改完 datadir 路径，记得同步修改 my.cnf 和 systemd 服务文件里对应的路径。这里我建议从一开始就规划一个二级目录结构，比如 /data/mysql/data 放数据，/data/mysql/binlog 放 binlog，避免挂载点直接作为 datadir 带来的麻烦。
5.3 服务刚起来几秒就退出，日志却只有一行
现象：systemctl start mysql 服务显示 active，几秒后变成 failed。错误日志里往往只有一行：
mysqld: error while loading shared libraries甚至有些情况日志里什么错误都没有，进程就消失了。
原因：两种可能。第一种是二进制缺依赖，ldd 检查后按第 2 章补齐。第二种是 pid 文件目录或 socket 目录不存在。mysqld 启动时要往 pid-file 路径写文件，如果父目录 /var/run/mysql 不存在，它会启动后立即退出，而这种错误未必写进 error log，排查起来非常费劲。
解决：先排除依赖库问题，再检查运行时目录：
mkdir -p /var/run/mysql chown mysql:mysql /var/run/mysql把 pid-file 的父目录建好，重新启动。如果你用的 my.cnf 里 socket 写 /tmp/mysql.sock，还要确认 /tmp 权限是 1777。有些系统的安全加固脚本会收紧 /tmp 权限，同样会让 MySQL 起不来。检查命令：
ls -ld /tmp输出 drwxrwxrwt 是正常状态，不是这个权限就先修正。
5.4 root 临时密码登录被拒：两条应急路径
现象：初始化时没记临时密码，或者复制错误日志里的密码时带了多余字符，导致 mysql -uroot -p 登录报 Access denied。
原因：MySQL 5.7 初始化的临时密码在错误日志里显示为：
[Note] A temporary password is generated for root@localhost: xxxxxx冒号后面那串才是密码。很多人把整行复制进去，多出来的冒号和空格自然导致认证失败。
解决：两条路。第一条，数据目录可以清空时，重新初始化：
rm -rf /data/mysql/* /usr/local/mysql/bin/mysqld --initialize --user=mysql --datadir=/data/mysql第二条，数据不能丢时，用 skip-grant-tables 临时进入：
# 临时启动，跳过权限表 /usr/local/mysql/bin/mysqld_safe --skip-grant-tables --skip-networking & /usr/local/mysql/bin/mysql -uroot进入后执行：
FLUSH PRIVILEGES; ALTER USER 'root'@'localhost' IDENTIFIED BY 'NewPassword@2024';改完密码后，务必停掉这个临时实例，用正常模式启动，确认 skip-grant-tables 已经从启动参数里去掉。带着这个参数长期运行等于裸奔，任何人都能无密码登录，属于高危操作。
5.5 远程连不上：bind-address、防火墙和账号授权三层检查
现象：本机用 mysql -uroot 正常，但远程客户端连接报 Can't connect to MySQL server，或者 socket 能连、TCP 连不上。
原因：三层原因都有可能。第一，my.cnf 里 bind-address 默认监听所有地址，但某些发行版会把它写成 127.0.0.1，只允许本地连接。第二，防火墙拦截 3306 端口。第三，用户授权只允许 localhost 登录。
解决：逐层排查。先确认监听地址：
ss -tnlp | grep 3306如果监听地址是 127.0.0.1:3306，修改 my.cnf：
bind-address = 0.0.0.0然后检查防火墙：
# iptables 直接查看 iptables -L -n | grep 3306 # firewalld 则用这个 firewall-cmd --list-port如果是云服务器，还要确认安全组是否放通 3306。最后确认账号授权，「第 4 章」创建的 'dev'@'192.168.%' 账号只允许 192.168 网段访问，如果你的客户端 IP 不在这个网段，要单独授权。三层全部排查完，远程连接基本能通。这里给个安全建议：不要用 0.0.0.0 暴露到公网，生产环境应该让 bind-address 指向内网网卡 IP，配合防火墙做端口限制。
6. 跑起来之后：完整性自检与性能基线
服务正常跑起来不算完，还要验证安装完整性和性能基线。先做一次系统表完整性检查：
/usr/local/mysql/bin/mysql_upgrade -uroot -p --socket=/tmp/mysql.sockmysql_upgrade 会扫描所有系统库，把缺失或过期的表结构升级到当前版本，输出 OK 表示检查通过。如果是从旧版本迁移过来的数据目录，这一步不能跳过，跳过会导致后续部分功能异常。
接着做一条验证 SQL，确认关键配置实际生效：
SELECT @@version, @@datadir, @@innodb_buffer_pool_size, @@max_connections;四列输出要和 my.cnf 预期一致。这里最容易出现的情况是，改完配置文件忘了重启，参数还是旧值，表面看部署成功了，实际配置没生效。
性能基线用 MySQL 自带的 mysqlslap 工具就能压一轮，不需要额外安装：
/usr/local/mysql/bin/mysqlslap \ --user=root --password=YourPassword \ --concurrency=10,50 \ --iterations=3 \ --number-int-cols=5 \ --number-char-cols=5 \ --auto-generate-sql \ --engine=innodbmysqlslap 会自动生成压测 SQL，输出不同并发下的平均耗时。注意这个工具只能做前后对比，不能代表真实业务负载。真实瓶颈往往在慢查询和索引设计上，别只看工具给出的数字。我的习惯是，压测完顺手打开慢查询日志，跑几天真实业务后回来分析，比任何基准测试都有说服力。
在这台 aarch64 服务器上部署 MySQL 5.7.32 时，我最深的体会是配置文件里每个参数都值得亲手验证，尤其 innodb_buffer_pool_size 和 max_connections，想当然抄别人配置经常翻车。部署类问题九成能从错误日志里找到线索，日志里每一行都有价值。如果你照这篇文章部署遇到问题，先用 tail 看 error.log，再对着第 5 章的清单逐条排查，希望帮到你。
本文还有配套的精品资源，点击获取
