MySQL 5.7.40 tar.gz离线安装与避坑指南
发布时间:2026/9/25 19:03:53 锦皓数字建站

简介本资源为 MySQL 5.7.40 在 Linux-glibc2.12 环境下的 x86_64 离线安装包面向需要在无外网或内网环境中部署关系型数据库的运维与后端开发人员。压缩包共 379 个文件约 646.59MB以 h 头文件、so 动态库、xml 配置、sql 脚本及 mysqld、mysql、mysqldump 等可执行程序为主完整覆盖服务端、客户端与常用管理工具解压后即可获得标准目录结构。目前已有 748 人学习下载。该版本在 InnoDB 引擎、JSON 支持、SQL 解析器与 TLS 1.2 加密等方面均有增强适合搭建稳定且功能丰富的数据库服务。借助包内附带的 my-default.cnf 配置样本、mysql_install_db 初始化脚本与 mysql_secure_installation 安全脚本读者可快速完成数据目录规划、参数调优与权限加固并对照目录结构理解各组件用途为后续复制、分区、索引优化及定期备份等生产实践打下基础。1. 为什么我还在用 mysql-5.7.40 的 tar.gz 包上周帮一个做工业数据采集的朋友处理现场问题他们的产线服务器跑的是麒麟 V10内网完全隔离不允许连外网源但业务系统依赖 MySQL 5.7 的一个特定行为——ONLY_FULL_GROUP_BY默认关闭。客户运维丢过来一个文件mysql-5.7.40-linux-glibc2.12-x86-64.tar.gz。这就是典型的离线安装场景没有 yum 源、没有 apt 源、没有 Docker 镜像仓库只有一个压缩包和一台干净的 Linux。这个 tar.gz 包是 MySQL 官方为 Linux 平台提供的通用二进制发行版编译时链接的是 glibc 2.12意味着它能覆盖从 CentOS 6 到 Rocky Linux 9、从麒麟 V10 到统信 UOS 的大部分国产化环境。它不依赖系统包管理器解压即用初始化后就能起服务。适合谁内网服务器运维、国产化替代项目交付工程师、需要固定 MySQL 小版本做兼容性测试的开发者。如果你手里正好有这个包或者正在找一份能照着敲的离线安装流程下面是我拆完这个包之后的完整记录。2. 拆包之前glibc 版本、目录布局与依赖检查2.1 先确认 glibc 版本别急着解压很多人拿到 tar.gz 第一反应是tar -zxvf但在 MySQL 5.7 的二进制包上这一步之前有个更重要的检查ldd --version。这个包编译时链接的是 glibc 2.12如果目标机器的 glibc 低于 2.12解压出来的mysqld根本跑不起来会直接报FATAL glibc error。反过来如果目标机器是较新的发行版glibc 版本高于 2.12 通常没问题但要注意 x86-64-v2 指令集的问题——部分国产 CPU 或老款 Intel 处理器可能不支持报错信息类似cpu does not support x86-64-v2。# 检查 glibc 版本确认 2.12 ldd --version | head -1 # 检查 CPU 是否支持 x86-64-v2 指令集 grep -o x86-64-v2 /proc/cpuinfo | head -1 # 查看系统架构必须是 x86_64 uname -m第一行输出类似ldd (GNU libc) 2.172.17 大于 2.12没问题。第二行如果没有任何输出说明 CPU 不支持 v2 指令集这个包里的mysqld可能无法启动需要考虑换用源码编译或更低版本的二进制包。第三行必须是x86_64如果是aarch64这个包完全不适用。2.2 解压后的目录结构里哪些文件真正有用解压这个 tar.gz 之后会得到一个以版本号命名的目录里面通常包含bin、lib、share、support-files等子目录。bin下面是所有可执行文件包括mysqld、mysql、mysqladmin、mysqldump等lib下面是一些共享库share下面是错误信息模板和 SQL 初始化脚本support-files里有一个mysql.server脚本是 SysV 风格的服务管理脚本。# 解压到 /usr/local 下这是常见做法 tar -zxvf mysql-5.7.40-linux-glibc2.12-x86-64.tar.gz -C /usr/local/ # 重命名目录方便后续配置 mv /usr/local/mysql-5.7.40-linux-glibc2.12-x86-64 /usr/local/mysql # 查看关键文件是否存在 ls /usr/local/mysql/bin/mysqld ls /usr/local/mysql/support-files/mysql.server重命名这一步不是必须的但强烈建议做。后面写配置文件、配 systemd 单元、设环境变量时路径短一点能少打很多字也少很多因为路径写错导致的翻车。support-files/mysql.server这个脚本在 CentOS 7 之前很常用现在更多用 systemd 管理但留着它没坏处里面有一些启动参数的参考值。2.3 依赖库检查libaio 和 numactl 不能少MySQL 5.7 的二进制包依赖两个常见的系统库libaio和numactl。libaio用于异步 I/Onumactl用于 NUMA 架构下的内存分配控制。很多最小化安装的 Linux 系统默认不带这两个库启动mysqld时会报error while loading shared libraries: libaio.so.1。# 检查 libaio 是否已安装 ldconfig -p | grep libaio # 检查 numactl 是否已安装 ldconfig -p | grep libnuma # 如果没有从系统安装盘或本地源安装 # CentOS/Rocky 系 rpm -ivh libaio-*.rpm numactl-libs-*.rpm # 麒麟/统信系通常用 apt 或 dpkg dpkg -i libaio1_*.deb libnuma1_*.debldconfig -p会列出当前系统所有可用的共享库。如果libaio那行没有输出就必须先装。离线环境下可以从同版本系统的安装 ISO 里提取对应的 rpm 或 deb 包。这一步不做后面初始化数据库时mysqld --initialize会直接失败而且报错信息不一定直观可能只显示一个退出码。3. 初始化与配置从 my.cnf 到 systemd 单元3.1 创建 mysql 用户和目录权限是第一个坑MySQL 不允许以 root 身份运行mysqld所以必须先创建一个专用的系统用户。同时数据目录、日志目录、临时目录都要提前建好并且把属主改成这个用户。权限不对是初始化失败最常见的原因没有之一。# 创建 mysql 用户组和用户-r 表示系统用户-s 指定不可登录 shell groupadd mysql useradd -r -g mysql -s /bin/false mysql # 创建数据目录和日志目录 mkdir -p /data/mysql/data mkdir -p /data/mysql/log mkdir -p /data/mysql/tmp # 修改属主和属组 chown -R mysql:mysql /data/mysql chmod -R 750 /data/mysql # 创建配置文件目录 mkdir -p /etc/mysql-s /bin/false是为了禁止这个用户登录系统纯粹作为服务运行身份。chmod 750意味着只有 mysql 用户和同组用户能进入这些目录其他用户没有任何权限。有些教程会写chmod 777那是给自己埋雷生产环境绝对不能这么干。数据目录的权限如果不对mysqld --initialize会报Cant create/write to file或者Permission denied。3.2 my.cnf 里必须显式设置的几个参数MySQL 5.7 的二进制包不带默认配置文件需要自己写一个/etc/my.cnf。下面这份配置是我在多个离线环境里用过的参数不多但每一个都有明确目的。[mysqld] # 基础路径 basedir /usr/local/mysql datadir /data/mysql/data tmpdir /data/mysql/tmp socket /data/mysql/mysql.sock pid-file /data/mysql/mysql.pid # 端口和绑定地址 port 3306 bind-address 0.0.0.0 # 字符集5.7 默认 latin1必须改成 utf8mb4 character-set-server utf8mb4 collation-server utf8mb4_general_ci # 关闭 ONLY_FULL_GROUP_BY这是很多老业务系统的硬需求 sql_mode STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION # 日志 log-error /data/mysql/log/error.log slow_query_log 1 slow_query_log_file /data/mysql/log/slow.log long_query_time 2 # InnoDB 相关 innodb_buffer_pool_size 1G innodb_log_file_size 256M innodb_flush_log_at_trx_commit 2 # 最大连接数 max_connections 500 [client] socket /data/mysql/mysql.sock default-character-set utf8mb4sql_mode这一行是重点。MySQL 5.7 默认的sql_mode包含ONLY_FULL_GROUP_BY很多从 5.6 迁移过来的业务 SQL 会直接报错。上面这份配置去掉了ONLY_FULL_GROUP_BY保留了其他严格模式选项。innodb_buffer_pool_size设为 1G 是个保守值实际应该根据服务器内存调整通常是物理内存的 50% 到 70%。innodb_flush_log_at_trx_commit 2在数据安全性和性能之间取了一个平衡如果对数据一致性要求极高改成 1。3.3 初始化数据库--initialize 与 --initialize-insecure 的区别MySQL 5.7 的初始化命令有两个变体--initialize会生成一个随机的 root 密码写在错误日志里--initialize-insecure会生成一个空密码的 root 账户。离线环境下我一般用后者因为不需要去翻错误日志找密码初始化完成后直接改密码就行。# 切换到 mysql 用户执行初始化 su - mysql -s /bin/bash -c /usr/local/mysql/bin/mysqld --defaults-file/etc/my.cnf --initialize-insecure # 检查初始化是否成功 ls /data/mysql/data/ # 应该能看到 ibdata1、mysql、sys 等目录和文件 # 查看错误日志确认没有报错 tail -20 /data/mysql/log/error.log--defaults-file必须放在所有其他参数之前这是 MySQL 的规矩顺序错了参数不生效。初始化完成后/data/mysql/data/下会出现ibdata1、ib_logfile0、ib_logfile1以及mysql、sys、performance_schema等系统数据库目录。如果这些没出现说明初始化失败去错误日志里找原因通常是权限问题或磁盘空间不足。3.4 配置 systemd 管理 mysqld 服务CentOS 7 以后systemd 是标准。写一个/etc/systemd/system/mysqld.service文件比用mysql.server脚本更可控。[Unit] DescriptionMySQL 5.7.40 Server Afternetwork.target Aftersyslog.target [Install] WantedBymulti-user.target [Service] Usermysql Groupmysql Typeforking PIDFile/data/mysql/mysql.pid ExecStart/usr/local/mysql/bin/mysqld --defaults-file/etc/my.cnf --daemonize ExecStop/usr/local/mysql/bin/mysqladmin --defaults-file/etc/my.cnf shutdown Restarton-failure RestartSec5 LimitNOFILE65536 [Install] WantedBymulti-user.targetTypeforking配合--daemonize参数让mysqld以守护进程方式运行。LimitNOFILE65536提高文件描述符上限避免高并发下报Too many open files。Restarton-failure让服务在异常退出时自动重启但如果是配置错误导致的启动失败会反复重启这时候需要先systemctl stop mysqld再排查。# 重新加载 systemd 配置 systemctl daemon-reload # 启动 MySQL systemctl start mysqld # 查看状态 systemctl status mysqld # 设置开机自启 systemctl enable mysqld启动后用mysqladmin检查服务是否响应。/usr/local/mysql/bin/mysqladmin --defaults-file/etc/my.cnf -u root status如果输出包含Uptime字样说明服务正常。如果报Cant connect to local MySQL server through socket去错误日志里看具体原因。4. 避坑与排查离线安装 MySQL 5.7 的五个血泪教训4.1 坑一libaio 缺失导致 mysqld 无法启动现象执行mysqld --initialize或systemctl start mysqld时没有任何输出或者只报一个模糊的退出码。查看错误日志发现日志文件根本没生成。原因mysqld二进制文件依赖libaio.so.1系统没有安装这个库时动态链接器直接拒绝加载进程在进入 main 函数之前就退出了所以连日志都来不及写。解决用ldd /usr/local/mysql/bin/mysqld | grep not found检查缺失的库。离线环境下从系统安装 ISO 的Packages目录里找到libaio的 rpm 包rpm -ivh安装。如果是麒麟或统信找对应的 deb 包用dpkg -i安装。4.2 坑二数据目录权限不对初始化报 Permission denied现象mysqld --initialize-insecure执行后错误日志里出现Cant create/write to file /data/mysql/data/ibdata1 (Errcode: 13 - Permission denied)。原因数据目录的属主不是 mysql 用户或者上层目录缺少执行权限。Linux 的目录权限中x权限决定能否进入目录如果/data/mysql对 mysql 用户没有x权限即使/data/mysql/data属主正确也进不去。解决chown -R mysql:mysql /data/mysql之后再chmod 750 /data/mysql /data/mysql/data。用su - mysql -s /bin/bash -c touch /data/mysql/data/test.txt验证 mysql 用户确实有写权限。4.3 坑三socket 文件路径不一致导致客户端连不上现象服务明明启动了mysql -u root -p却报ERROR 2002 (HY000): Cant connect to local MySQL server through socket /tmp/mysql.sock。原因my.cnf里配置的socket路径是/data/mysql/mysql.sock但客户端默认去/tmp/mysql.sock找。客户端和服务端的 socket 路径不一致。解决在my.cnf的[client]段里也加上socket /data/mysql/mysql.sock或者在连接时显式指定-S /data/mysql/mysql.sock。我一般会在[client]段里写死省得每次敲命令都要带路径。4.4 坑四ONLY_FULL_GROUP_BY 导致业务 SQL 报错现象业务系统迁移过来后大量SELECT语句报ERROR 1055 (42000): Expression #1 of SELECT list is not in GROUP BY clause and contains nonaggregated column。原因MySQL 5.7 默认开启ONLY_FULL_GROUP_BY要求SELECT列表中的非聚合列必须出现在GROUP BY中。很多老系统在 5.6 上跑得好好的 SQL到 5.7 直接挂。解决在my.cnf的sql_mode中去掉ONLY_FULL_GROUP_BY然后重启服务。注意不要直接把sql_mode设为空那样会丢掉其他严格模式检查可能引入更隐蔽的数据问题。上面 3.2 节给出的sql_mode配置是一个比较稳妥的折中。4.5 坑五glibc 版本过高或 CPU 指令集不兼容现象在较新的发行版上启动mysqld报FATAL glibc error: cpu does not support x86-64-v2或者直接Illegal instruction (core dumped)。原因这个二进制包编译时面向的是较老的 CPU 架构但某些新发行版默认启用了 x86-64-v2 指令集优化或者反过来老 CPU 不支持 v2 指令集而二进制包要求 v2。两种情况都可能发生。解决先grep -o x86-64-v2 /proc/cpuinfo确认 CPU 是否支持。如果不支持这个包用不了需要换用源码编译或找更低版本的二进制包。如果支持但 glibc 版本过高导致兼容性问题可以尝试在容器里跑或者用patchelf修改二进制的解释器路径但这个操作风险较高生产环境慎用。5. 进阶用 mysqladmin 做健康检查与慢查询定位5.1 用 mysqladmin 快速判断服务状态mysqladmin是 MySQL 自带的管理工具除了status还有几个子命令在排查问题时很顺手。# 查看当前连接数、运行时间、查询量 /usr/local/mysql/bin/mysqladmin --defaults-file/etc/my.cnf -u root -p extended-status | grep -E Threads_connected|Uptime|Questions # 查看当前正在执行的查询 /usr/local/mysql/bin/mysqladmin --defaults-file/etc/my.cnf -u root -p processlist # 查看主从复制状态如果配了从库 /usr/local/mysql/bin/mysqladmin --defaults-file/etc/my.cnf -u root -p replication statusextended-status输出的指标很多我一般关注Threads_connected当前连接数、Threads_running正在执行的线程数、Questions总查询数。如果Threads_running持续偏高说明有慢查询堆积。processlist能看到每个连接的来源、执行的 SQL 和状态State列显示Sending data或Copying to tmp table时通常意味着有需要优化的查询。5.2 慢查询日志的开启与解读在my.cnf里已经配了慢查询日志但long_query_time 2意味着超过 2 秒的查询才会被记录。实际排查时可以临时调低这个值比如设为 0.5 秒跑一段时间后再分析。-- 动态修改慢查询阈值不需要重启 SET GLOBAL long_query_time 0.5; -- 确认修改生效 SHOW VARIABLES LIKE long_query_time; -- 查看慢查询日志路径 SHOW VARIABLES LIKE slow_query_log_file;慢查询日志的格式是纯文本每条记录包含执行时间、锁定时间、返回行数、扫描行数和完整的 SQL 语句。用mysqldumpslow工具可以快速汇总。# 按执行时间排序显示前 10 条慢查询 /usr/local/mysql/bin/mysqldumpslow -s t -t 10 /data/mysql/log/slow.log # 按扫描行数排序 /usr/local/mysql/bin/mysqldumpslow -s r -t 10 /data/mysql/log/slow.log-s t表示按查询时间排序-s r表示按返回记录数排序。输出里会显示同类查询的执行次数、平均时间、平均扫描行数。如果某条查询扫描行数远大于返回行数说明索引没走对需要检查执行计划。5.3 一个具体的索引优化案例之前遇到一个查询在 500 万行的表上跑了 8 秒多。慢查询日志里显示扫描了 480 万行返回 3 行。用EXPLAIN看执行计划发现type是ALL全表扫描。-- 查看执行计划 EXPLAIN SELECT id, name, created_at FROM orders WHERE status pending AND created_at 2024-01-01 ORDER BY created_at DESC LIMIT 10;输出里key列是NULL说明没用到索引。rows列是 4800000全表扫描。解决方案是建一个联合索引。-- 创建联合索引顺序很重要等值条件在前范围条件在后 ALTER TABLE orders ADD INDEX idx_status_created (status, created_at);建完索引后再EXPLAINtype变成rangerows降到 2000 左右查询时间从 8 秒降到 0.05 秒。联合索引的列顺序原则是等值查询的列放前面范围查询的列放后面排序的列如果和范围列一致可以省掉filesort。5.4 离线环境下的备份习惯离线环境没有云备份所有数据安全都靠本地策略。我习惯在每天凌晨用mysqldump做一次逻辑备份保留最近 7 天。#!/bin/bash # 每天凌晨 2 点执行备份到 /data/backup/mysql/ BACKUP_DIR/data/backup/mysql DATE$(date %Y%m%d) /usr/local/mysql/bin/mysqldump --defaults-file/etc/my.cnf -u root -pyour_password \ --single-transaction --routines --triggers --events \ --all-databases | gzip ${BACKUP_DIR}/full_${DATE}.sql.gz # 删除 7 天前的备份 find ${BACKUP_DIR} -name full_*.sql.gz -mtime 7 -delete--single-transaction保证 InnoDB 表的一致性快照不锁表。--routines、--triggers、--events分别备份存储过程、触发器和事件调度器。gzip压缩后一个几十 GB 的数据库通常能压到几 GB。这个脚本放在 crontab 里0 2 * * * /data/scripts/backup_mysql.sh。从那以后我每次交付离线 MySQL 环境都会在初始化完成后立刻跑一遍ldd检查依赖、确认sql_mode配置、验证 socket 路径最后把备份脚本挂上 crontab。这三步走完基本不会再出大问题。希望帮到你。本文还有配套的精品资源点击获取
锦
锦皓数字建站
深耕本土企业品牌数字化升级,专注原创端正雅致商务官网,从视觉设计到稳定运维全程保驾护航。