必须显式指定-dcmake_system_processor=aarch64，否则cmake_system_processor被识别为generic或空值，导致未启用arm64原生指令、原子操作链接失败及优化失效；同时需安装libatomic、用patchelf替换libtinfo.so.5为libtinfo.so.6、禁用libedit，并强制-dwith_ssl=system以避免openssl握手崩溃。
不能直接复制 x86 的 MySQL 二进制文件到 ARM 服务器上运行——指令集不兼容，mysqld 启动时大概率报 Illegal instruction 或直接 segfault。必须重新编译，或使用官方/信创厂商提供的 aarch64 架构专用包。
为什么 cmake 不加 -DCMAKE_SYSTEM_PROCESSOR=aarch64 就会失败
cmake 默认通过 uname -m 推断目标平台，但部分国产 ARM 系统（如 EulerOS、Kylin V10）的 CMake 版本较旧，或系统内核伪装字段异常，导致 CMAKE_SYSTEM_PROCESSOR 被识别为 generic 或空值。结果是：
- 生成的代码未启用 ARM64 原生指令（如 LSE atomics），运行时触发
__atomic_store_16链接失败 - 优化标志（如
-march=armv8-a+crypto+lse）未生效，性能降级甚至崩溃 - 部分头文件路径和符号查找逻辑错位，
make阶段报undefined reference to 'tgetent'
必须显式传参：cmake -DCMAKE_SYSTEM_PROCESSOR=aarch64 ...，这是 ARM64 编译的“开关”，不是可选项。
libatomic、libtinfo.so.6、libedit 这三个依赖怎么处理
ARM64 下这三个库最容易引发启动失败，且错误现象高度相似（都是 error while loading shared libraries），但原因不同：
-
libatomic：GCC 内建原子操作在 aarch64 上依赖该库，缺它会报undefined reference to '__atomic_store_16'；需提前装：sudo yum install libatomic（EulerOS/Kylin）或sudo apt install libatomic1（Debian/Ubuntu ARM64） -
libtinfo.so.5：MySQL 官方源码编译出的二进制仍硬编码链接 v5，但国产系统（如 Kylin V10 SP1、OpenAnolis）已只提供libtinfo.so.6；禁止用软链接（会导致 runtime symbol mismatch），改用：patchelf --replace-needed libtinfo.so.5 libtinfo.so.6 /usr/local/mysql/bin/mysqld -
libedit：ARM 平台下静态链接常因 symbol 版本冲突失败（如rl_bind_key版本不匹配），且 MySQL CLI 实际不依赖它；直接禁用：-DWITH_LIBEDIT=OFF
WITH_SSL=system 是必须的，别碰 bundled OpenSSL
MySQL 自带的 bundled OpenSSL（或 BoringSSL）在 ARM64 上对 AEAD 加密套件（如 TLS_AES_256_GCM_SHA384）支持不完整，握手阶段极易 segfault。现象是服务能启，但客户端一连就崩，日志里看不到明显错误。
解决方式很明确：
- 强制用系统 OpenSSL：
-DWITH_SSL=system - 确保系统已装：
openssl-devel（RPM 系）或libssl-dev（DEB 系） - 验证：
pkg-config --modversion openssl输出 ≥ 1.1.1k（飞腾某些定制内核要求 ≥ 3.0.0） - 不要加
-DOPENSSL_INCLUDE_DIR或-DOPENSSL_LIBRARY——让 cmake 自动探测更稳
最易被忽略的是 patchelf 修改动态链接项这一步：很多人卡在 libtinfo.so.5 报错后去改 /etc/ld.so.conf.d/ 或加 LD_LIBRARY_PATH，但无效——因为路径存在不代表符号兼容。必须重写二进制的 .dynamic 段，这点在鲲鹏/飞腾现场部署中反复验证过。
