企业官网建设流程全解析

简介：这份资源是 MySQL 4.1.18 的 Linux 二进制安装包，面向需要在 PC 架构 Linux 系统上搭建轻量级数据库的初学者、运维入门者及小型项目开发者。它基于 glibc23 与 GNU 工具链编译，解压后即可按官方文档完成配置与安装，省去源码编译环节，适合用于学习数据库管理基础或作为早期应用的测试后台。压缩包共 1269 个文件，约 24.48MB，以 result、test、opt、h、txt、inc、require 等测试与头文件为主，同时包含 cfg、cnf、sh、sql 等配置和脚本文件，以及 mysqld、mysqladmin、mysqldump、mysqlcheck 等核心服务与管理工具，目录结构完整保留了官方发行版的测试套件与文档。目前已有 131 人学习下载。通过该包，读者可实践 root 初始空密码修改、mysql 与 test 内置库的用途辨析、GRANT/REVOKE 权限分配，以及 mysqldump 备份、mysql_secure_installation 加固等日常运维操作，为后续掌握更高版本 MySQL 打下基础。

1. 老 i686 机器上跑 MySQL：这个 tar 包到底解决什么问题

手里有一台还在服役的 32 位 x86 老机器，或者一台国产化环境里被限定在 i686 用户态的工控机，你想在上面装个 MySQL 存点业务数据，结果发现官网下载页早就把 32 位 Linux 的二进制包下架了，能下到的只有源码包，编译一次动辄半小时起步，还大概率卡在某个 C++ 头文件上。这时候mysql-standard-4.1.18-pc-linux-gnu-i686-glibc23.tar这类命名规整的 tar 包就成了救命稻草——它是 MySQL 官方在 4.1 时代为 32 位 x86 Linux 平台预编译好的二进制发行版，解压即用，不依赖目标机的编译工具链。

这个包名本身就是一份说明书：mysql-standard是标准版（非 Max 版），4.1.18是版本号，pc-linux-gnu表示面向 PC 上的 GNU/Linux，i686是目标 CPU 架构，glibc23说明它链接的是 glibc 2.3 系列。理解这套命名规则，你就能判断它能不能落在你的机器上。本文面向的是需要在老旧或受限 Linux 环境里快速拉起 MySQL 的运维和嵌入式开发者，重点讲清楚这个 tar 包怎么解、怎么初始化、怎么配、以及 glibc 和架构这两道坎怎么过。

2. 拆开包名：i686、glibc23 与 tar 包的分发逻辑

2.1 为什么是预编译二进制而不是源码编译

在老机器上源码编译 MySQL 的痛点非常具体：4.1 时代的代码对 GCC 版本敏感，新版 GCC 编译老代码经常报隐式声明错误；32 位环境下编译大文件容易触发内存不足；交叉编译工具链配置本身就是一门玄学。预编译二进制包把这些问题在发布方那边一次性解决掉，你拿到的是一堆已经链接好的可执行文件和库，省掉的是整条工具链的折腾。

代价是灵活性。二进制包绑定了编译时的 glibc 版本和 CPU 指令集，目标机必须满足这些前提，否则就是FATAL glibc error或者cannot execute binary file。所以用这类包的第一步不是解压，而是核对目标机环境。

2.2 i686 与 glibc23 这两个标签的实际含义

i686指的是 Intel P6 微架构及之后的 32 位 x86 处理器，指令集覆盖到 SSE2 之前的那一批。它和i386、i586的区别在于编译时启用的指令集不同，i686 包在真正的 486 机器上跑不起来，但在绝大多数 32 位 x86 机器上没问题。判断自己的机器是不是 i686，直接看uname -m，输出i686或i386都属于 32 位 x86 家族，通常可以尝试。

glibc23表示这个包在 glibc 2.3 环境下编译并链接。glibc 的向后兼容性总体不错，高版本 glibc 一般能跑低版本编译的程序，但反过来不行。所以这个包在 glibc 2.3 及以上的系统上通常能跑，在更老的 glibc 2.2 系统上就会报符号找不到。用ldd --version看目标机的 glibc 版本，这是解压前必做的一步。

2.3 tar 包的分发结构和解压前的环境核对

这类官方二进制 tar 包解压后通常是一个以版本和平台命名的目录，里面包含bin、libexec、share、include、man等子目录。bin下是mysqld、mysql、mysqladmin等客户端和服务端程序，libexec下是mysqld的实际可执行文件（部分版本放在 bin），share下是错误信息文件和字符集。

解压前先跑三条命令核对环境：

uname -m # 看 CPU 架构，期望 i686 或 i386 ldd --version | head -1 # 看 glibc 版本，期望 2.3 及以上 df -h /usr/local # 看目标分区剩余空间，MySQL 数据目录建议留 2G 以上

三条都过了再解压。如果uname -m返回x86_64，说明是 64 位机器，理论上能跑 32 位程序，但需要系统装了 32 位兼容库，否则会报找不到ld-linux.so.2。这种情况要么装兼容库，要么换 64 位版本的包，别硬扛。

3. 从解压到首次启动：把 mysqld 拉起来的最小路径

3.1 解压与目录归位

官方 tar 包解压后目录名很长，实际部署时一般会重命名或软链到一个固定路径，方便后续配置和脚本引用。下面这套操作把包放到/usr/local/mysql，这是最常见的约定。

# 假设 tar 包已经上传到 /tmp cd /usr/local tar -zxvf /tmp/mysql-standard-4.1.18-pc-linux-gnu-i686-glibc23.tar # 解压后目录名很长，重命名为 mysql mv mysql-standard-4.1.18-pc-linux-gnu-i686-glibc23 mysql # 确认关键可执行文件存在 ls -l /usr/local/mysql/bin/mysqld_safe ls -l /usr/local/mysql/bin/mysql

tar -zxvf里的z表示走 gzip 解压，x是解包，v显示过程，f指定文件名。如果目标机没有 tar 命令（极简系统可能出现），需要先用包管理器装上，或者用busybox tar替代。解压后目录属主是当前用户，如果打算用独立的 mysql 用户跑服务，后面要改属主。

3.2 建立 mysql 用户与数据目录

MySQL 服务不应该用 root 跑，标准做法是建一个专用的低权限用户。数据目录单独放，方便备份和迁移。

# 建 mysql 用户和组，禁止登录 groupadd mysql useradd -g mysql -s /sbin/nologin mysql # 建数据目录并授权 mkdir -p /usr/local/mysql/data chown -R mysql:mysql /usr/local/mysql chmod 750 /usr/local/mysql/data

-s /sbin/nologin是关键，防止这个账户被用来登录系统。数据目录权限给 750，保证只有 mysql 用户和同组能读写。如果数据目录放在独立分区，记得在/etc/fstab里配好挂载，别等重启后数据目录空了才发现。

3.3 初始化系统表与首次启动

4.1 时代的初始化方式和 5.7 之后不同，它用的是mysql_install_db脚本，而不是mysqld --initialize。这一步会创建mysql系统库和test库，并生成初始的 root 账户。

cd /usr/local/mysql # 初始化系统表，指定数据目录和用户 ./bin/mysql_install_db --user=mysql --datadir=/usr/local/mysql/data # 后台启动 mysqld_safe，指定配置文件 ./bin/mysqld_safe --user=mysql --datadir=/usr/local/mysql/data &

mysql_install_db执行时会往数据目录写一堆.frm和.MYD、.MYI文件，这是 MyISAM 时代的存储格式。如果这一步报FATAL ERROR: Could not find mysqld，说明脚本没找到可执行文件，检查basedir参数或当前工作目录。启动后看ps -ef | grep mysqld确认进程在，再用客户端连一下。

# 用 socket 连接，首次 root 无密码 ./bin/mysql -u root -S /tmp/mysql.sock # 进去后立刻设密码 mysql> SET PASSWORD FOR 'root'@'localhost' = PASSWORD('你的密码'); mysql> FLUSH PRIVILEGES;

-S指定 socket 文件路径，4.1 默认 socket 在/tmp/mysql.sock。如果连不上报ERROR 2002，八成是 socket 路径不对或者 mysqld 没起来，先看错误日志。

3.4 配置文件 my.cnf 的关键参数

4.1 会按顺序读/etc/my.cnf、$MYSQL_HOME/my.cnf、~/.my.cnf。生产环境建议在/etc/my.cnf里写一份明确的配置，避免依赖默认值。

[mysqld] basedir = /usr/local/mysql datadir = /usr/local/mysql/data socket = /tmp/mysql.sock port = 3306 user = mysql # 32 位环境内存有限，缓冲池别开太大 key_buffer_size = 64M max_connections = 100 table_open_cache = 128 # 字符集，4.1 开始支持 utf8 character-set-server = utf8 default-storage-engine = MyISAM [client] socket = /tmp/mysql.sock default-character-set = utf8

key_buffer_size是 MyISAM 索引缓存，32 位进程地址空间有限，给 64M 比较稳妥，给太大反而可能启动失败。max_connections按实际并发调，老机器上 100 够用。字符集设 utf8 能避免中文乱码，但要注意 4.1 的 utf8 是每字符最多 3 字节，和后来 5.5 的 utf8mb4 不是一回事。

4. 避坑与排查：glibc、架构和启动失败的血泪经验

4.1 现象：执行 mysqld 报 FATAL glibc error 或 version GLIBC_2.3 not found

原因：目标机 glibc 版本低于包编译时的版本，或者 glibc 虽然版本够但缺少某些符号。这种情况在国产化精简系统上尤其常见，系统自带的 glibc 被裁剪过。

解决：先用ldd --version确认版本。如果版本确实低，升级 glibc 风险极高，容易把系统搞崩，不建议在生产机上直接替换。更稳的做法是找一台 glibc 版本匹配的机器编译，或者用静态链接的版本。如果只是缺符号，用strings /lib/libc.so.6 | grep GLIBC_2.3看目标库到底提供了哪些版本符号，对比objdump -T mysqld | grep GLIBC看程序需要哪些。

4.2 现象：uname -m 是 x86_64，跑 32 位 mysqld 报 cannot execute binary file

原因：64 位系统默认没装 32 位运行时库，内核虽然支持执行 32 位程序，但动态链接器ld-linux.so.2不存在。

解决：装 32 位兼容库。Debian/Ubuntu 系装libc6:i386，RHEL/CentOS 系装glibc.i686。装完用file /usr/local/mysql/bin/mysqld确认是 ELF 32-bit，再跑ldd看依赖是否都解析到。如果系统源里没有 32 位库，这条路基本走不通，换 64 位包更实际。

4.3 现象：mysql_install_db 执行到一半报 Cannot create/write to file，权限拒绝

原因：数据目录属主不对，或者当前用户对 basedir 没有读权限。常见于用 root 解压后直接切 mysql 用户跑初始化。

解决：chown -R mysql:mysql /usr/local/mysql把整个目录属主改掉，数据目录权限 750。如果开了 SELinux，还要看ls -Z的上下文，必要时用chcon -R -t mysqld_db_t /usr/local/mysql/data调整。SELinux 的拒绝日志在/var/log/audit/audit.log，用ausearch -m avc能查到具体拒绝项。

4.4 现象：mysqld_safe 启动后进程秒退，错误日志里写 Table 'mysql.host' doesn't exist

原因：初始化没跑完或者数据目录被清过，系统表缺失。4.1 的权限系统依赖mysql库里的user、db、host等表，缺一个都起不来。

解决：停掉进程，清空数据目录，重新跑mysql_install_db。注意清空前确认目录里没有业务数据。如果反复初始化都失败，看错误日志里第一条报错，通常是磁盘满或者 inode 耗尽，用df -i查一下。

4.5 现象：客户端连不上，报 ERROR 2002 (HY000) Can't connect to local MySQL server through socket

原因：socket 文件路径不匹配，或者 mysqld 根本没监听。4.1 默认 socket 在/tmp/mysql.sock，但有些系统/tmp被清理过，或者 my.cnf 里改了路径而客户端没读到。

解决：先ps -ef | grep mysqld确认服务在跑，再netstat -lnp | grep mysql看监听状态。客户端连接时显式指定-S /tmp/mysql.sock，或者用-h 127.0.0.1 -P 3306走 TCP。如果 my.cnf 里改了 socket 路径，确保[mysqld]和[client]两段都改了，只改一段就会出现服务端和客户端各说各话的情况。

5. 让老版本 MySQL 稳下来：备份、字符集与迁移的实操技巧

5.1 用 mysqldump 做逻辑备份并排除大表

4.1 自带的mysqldump功能已经够用，但默认会锁表，在老机器上锁久了业务会受影响。备份时加上--single-transaction对 MyISAM 无效，MyISAM 只能用--lock-tables，所以备份窗口要选在低峰期。

# 备份整个库，排除日志表 /usr/local/mysql/bin/mysqldump \ -u root -p \ --lock-tables \ --ignore-table=appdb.access_log \ --ignore-table=appdb.error_log \ appdb > /backup/appdb_$(date +%Y%m%d).sql

--ignore-table可以多次出现，用来跳过那些体积大又不需要备份的日志表。备份文件建议压缩后异地存一份，gzip一下能省不少空间。恢复时用mysql -u root -p appdb < 备份文件，注意先建库。

5.2 字符集从 latin1 迁到 utf8 的注意点

4.1 默认字符集是 latin1，存中文会乱码。迁移时不能直接ALTER TABLE ... CONVERT TO CHARACTER SET utf8就完事，因为 latin1 里存的中文其实是错误的字节序列，转换后会变成问号。正确做法是先把数据导成 latin1 的 SQL 文件，用iconv转成 utf8，再导入新库。

# 导出时指定 latin1 mysqldump --default-character-set=latin1 -u root -p appdb > appdb_latin1.sql # 用 iconv 转码 iconv -f latin1 -t utf8 appdb_latin1.sql > appdb_utf8.sql # 导入前确保目标库是 utf8 mysql -u root -p -e "CREATE DATABASE appdb_new DEFAULT CHARACTER SET utf8;" mysql --default-character-set=utf8 -u root -p appdb_new < appdb_utf8.sql

iconv转换时如果遇到无法映射的字节会报错，加-c参数可以跳过非法字符，但会丢数据，建议先不加-c跑一遍看报错位置，确认是脏数据再决定怎么处理。

5.3 验证服务稳定性的三个观察点

老机器上跑 MySQL，稳定性比性能更重要。我一般会盯三个指标：一是SHOW STATUS LIKE 'Threads_connected'看连接数有没有异常增长，连接泄漏会很快把max_connections打满；二是SHOW STATUS LIKE 'Table_locks_waited'看表锁等待，MyISAM 的表锁在老机器上容易成为瓶颈；三是看错误日志里有没有反复出现的警告，比如Disk is full或者Table is marked as crashed。

-- 连接数观察 SHOW STATUS LIKE 'Threads_connected'; SHOW VARIABLES LIKE 'max_connections'; -- 表锁等待 SHOW STATUS LIKE 'Table_locks_waited'; SHOW STATUS LIKE 'Table_locks_immediate'; -- 慢查询，4.1 需要手动开 SHOW VARIABLES LIKE 'log_slow_queries';

Table_locks_waited和Table_locks_immediate的比值能反映锁竞争程度，如果 waited 持续增长，说明有查询在抢表锁，考虑加索引或者把热点表换成 InnoDB。4.1 已经支持 InnoDB，但默认没启用，需要在 my.cnf 里加skip-innodb的反向配置或者直接不写skip-innodb。

5.4 迁移到新版本时的兼容性检查

如果哪天要把数据从 4.1 迁到 5.7 或 8.0，直接导 SQL 文件大概率会踩坑。4.1 的PASSWORD()函数生成的密码哈希算法和 5.7 不同，用户表不能直接导。TYPE=MyISAM这种老语法在新版本里虽然还能认，但会有警告。存储过程里如果用了\G或者老式注释，也可能解析失败。

我的习惯是先在测试环境用mysqldump --compatible=mysql40导一份，再往新版本导，看报错逐条改。字符集方面，4.1 的 utf8 到 5.7 的 utf8 是兼容的，但如果要上 utf8mb4，得确认所有表的字段长度够，因为 utf8mb4 每字符最多 4 字节，VARCHAR(255)在索引里可能超长。

这套东西我在几台老工控机上反复折腾过，最深的教训是：别在 glibc 版本上赌运气，解压前花两分钟核对环境，比事后花两小时排查FATAL glibc error划算得多。老版本 MySQL 能跑起来不难，难的是让它稳定跑下去，备份和监控这两件事从第一天就要做。希望帮到你。

本文还有配套的精品资源，点击获取