MySQL 8.4 LTS 二进制 tar 包部署必须严格匹配 glibc 版本（如 mysql-8.4.10-linux-glibc2.28-x86_64.tar.xz 要求系统 glibc ≥ 2.28）、提前创建 mysql 用户、初始化前在 my.cnf 中固定 lower_case_table_names=1，且 datadir 与 basedir 分离并正确赋权，否则必然启动失败或数据损坏。
直接用 tar 包装 MySQL 8.4 LTS 是可行的，但必须严格匹配 glibc 版本、提前创建专用用户、初始化前固定 lower_case_table_names，否则启动失败或数据目录损坏几乎是必然结果。
确认系统环境是否满足 MySQL 8.4.10 的硬性要求
MySQL 8.4 要求 glibc >= 2.17，但实际下载包名里已标明适配版本，比如 mysql-8.4.10-linux-glibc2.28-x86_64.tar.xz 表示它只兼容 glibc 2.28 及以上。运行 ldd --version 查看当前系统版本，低于包内标注值就别强装——不是报错就是运行时崩溃。
其他关键点：
- 内核建议 ≥ 3.10（Rocky Linux 9.6 / CentOS 7 都满足）
- SELinux 建议设为
disabled，或至少配置mysqld_t上下文，否则mysqld启动后立刻被拒绝访问数据目录 - 防火墙要放行
3306，或临时停用：systemctl stop firewalld
解压后必须用软链接统一入口，别直接改文件夹名
解压命令本身没问题：tar -xf mysql-8.4.10-linux-glibc2.28-x86_64.tar.xz，但后续操作容易出错：有人直接 mv 成 mysql 放进 /usr/local，结果升级时路径散落、mysqld_safe 找不到 mysqld。
正确做法是保留原始文件夹名，再建软链接：
cd /opt/mysql ln -s mysql-8.4.10-linux-glibc2.28-x86_64 mysql
这样所有脚本和配置里写 /opt/mysql/mysql/bin/mysqld 就永远指向最新版，升级只需换链接目标。
同时把 /opt/mysql/mysql/bin 加进 PATH，但别改 /etc/profile——用 /etc/profile.d/mysql.sh 更干净，避免污染全局环境。
my.cnf 里 lower_case_table_names=1 必须在初始化前写死
这个参数一旦在 mysqld --initialize 之后修改，MySQL 就拒绝启动，报错类似 InnoDB: Assertion failure in file ... dict0dict.cc line 1234，修复代价远高于重装。
Linux 默认是 0（表名大小写敏感），但多数应用依赖 1（不敏感）。所以配置文件里必须明确写：
[mysqld] lower_case_table_names=1 datadir=/data/mysql/3306/data basedir=/opt/mysql/mysql
注意：datadir 路径不能和 basedir 混在一起，必须分开；datadir 目录得由 mysql 用户拥有，且不能有残留文件——初始化前手动清空一次更稳妥。
初始化失败常见原因和绕过技巧
执行 /opt/mysql/mysql/bin/mysqld --initialize --user=mysql --console 后没输出密码、日志里只有 Aborting，大概率是以下三者之一：
-
datadir权限不对：chown -R mysql:mysql /data/mysql/3306缺一不可 -
log_error路径不可写，或父目录不存在，MySQL 不会自动创建多级目录 - 内存不足：MySQL 8.4 初始化默认尝试分配几百 MB 内存，虚拟机内存 --innodb-buffer-pool-size=64M 参数压低
如果还是卡住，先删掉 datadir 全部内容，加 --log-error-verbosity=3 重新跑，错误会更具体。别信“跳过初始化”的说法——--skip-grant-tables 在 8.4 里无法绕过密码生成阶段。
最易被忽略的是：初始化成功后生成的临时密码藏在 log_error 指定的文件里，不是终端输出。哪怕加了 --console，也得去翻日志找 A temporary password is generated for root@localhost: 这一行。漏掉这步，后续连不上就只能重来。
