简介这份资源是 MySQL 4.1.18 的 Linux 二进制安装包面向需要在 PC 架构 Linux 系统上搭建关系型数据库的初学者与小型项目开发者。它基于 GNU 工具链并依赖 glibc23 库解压后即可按官方文档完成配置与安装省去自行编译的繁琐适合用作数据库管理入门、SQL 基础练习或轻量级应用后台的实践环境。压缩包共 1269 个文件约 24.48MB内含可执行程序、测试用例、配置模板与文档手册等多类内容result、test 等文件对应功能验证与回归测试h、inc 等为开发头文件cnf、cfg 提供配置样例readme、txt 则记录安装与使用说明目录结构完整便于按模块查阅。目前已有 131 人学习下载。通过该包读者可实际运行 mysqld、mysqladmin、mysqldump 等工具熟悉 root 账户初始化、权限分配与数据备份流程并借助自带测试脚本理解索引、视图、触发器和存储过程等基础特性为后续版本升级与运维打下扎实根基。1. 老 i686 机器上跑 MySQL这个 tar 包到底解决什么问题手里有一台还在服役的 32 位 x86 老机器或者一个跑着老版本国产 Linux 的隔离环境想装个 MySQL 存点业务数据结果mysql官网下载页翻到底也找不到能用的二进制包——这个场景我遇到过不止一次。mysql-standard-4.1.18-pc-linux-gnu-i686-glibc23.tar就是为这种局面准备的它是 MySQL 4.1.18 官方编译好的 32 位 Linux 二进制发行包i686说明目标 CPU 是 32 位 x86 架构glibc23说明它链接的是 glibc 2.3 时代的 C 运行库tar说明它是个解压即用的绿色包不需要rpm或apt参与。它解决的核心问题是在没有包管理器、没有编译工具链、甚至没有网络的老环境里把一套能跑的 MySQL 服务端和客户端落到磁盘上。适合谁适合维护老旧工控机、内网隔离设备、教学实验环境的运维和嵌入式工程师。不适合谁不适合追求新特性、需要 JSON 字段或窗口函数的生产系统——4.1 这个版本连存储过程都还没有。2. 拆开这个 tar 包目录结构、依赖链和选型判断2.1 解压后你会看到什么先把包解开别急着初始化。用tar -zxvf解到/usr/local下这是老版本 MySQL 二进制包的惯例路径。# 解压到 /usr/local注意 -C 指定目标目录 tar -zxvf mysql-standard-4.1.18-pc-linux-gnu-i686-glibc23.tar -C /usr/local # 解压后会得到一个长名字目录改短方便后续引用 cd /usr/local mv mysql-standard-4.1.18-pc-linux-gnu-i686-glibc23 mysql解压完ls /usr/local/mysql你会看到几个关键目录bin放mysqld、mysql、mysqladmin这些可执行文件scripts放mysql_install_db初始化脚本share放错误信息文件和字符集support-files放启动脚本模板和示例配置。没有data目录因为数据目录要你自己初始化生成。这个结构和现代 MySQL 8.x 的 tar 包逻辑一致只是少了lib下的插件目录。参数说明-z表示用 gzip 解压-x是提取-v显示过程-f指定文件名。顺序上-f必须紧跟文件名写成tar -zxvf file.tar没问题但tar -zxfv file.tar在某些老 tar 上会报错。如果目标机器连tar都没有热词里有人搜「linux没有tar命令」那得先想办法把tar二进制弄进去或者用busybox tar替代。2.2 glibc23 这个标签意味着什么glibc23不是随便写的。它表示这个二进制包在编译时链接的是 glibc 2.3.x 系列。glibc 是 Linux 上最底层的 C 库几乎所有用户态程序都依赖它。二进制程序在运行时需要找到对应版本的libc.so.6如果目标系统的 glibc 版本低于编译时的版本程序会直接报FATAL: kernel too old或者version GLIBC_2.3 not found。这里有个反直觉的点glibc 版本号不是越高越好。高版本 glibc 编译出来的程序拿到低版本系统上跑不了反过来低版本编译的程序在高版本系统上通常能跑。所以glibc23这个包的可移植性其实不错——只要目标系统的 glibc 不低于 2.3基本都能启动。现代发行版比如 openEuler、麒麟 V10 的 glibc 都在 2.28 以上跑这个包没问题。但要注意热词里提到的fatal glibc error: cpu does not support x86-64-v2——那是 64 位系统上 CPU 指令集的问题和这个 32 位包无关别混为一谈。2.3 为什么选二进制包而不是源码编译在老机器上编译 MySQL 源码是件痛苦的事。4.1 时代的源码编译需要gcc、make、ncurses、openssl一堆依赖编译一次动辄半小时以上中间还可能因为缺少某个头文件中断。二进制包的优势是解压即用不依赖编译工具链不挑内核小版本。代价是你没法针对特定 CPU 做指令集优化也没法裁剪不需要的存储引擎。我一般会这样判断如果目标机器有完整的开发工具链且 CPU 性能尚可源码编译能拿到更好的性能如果目标机器是个连gcc都没装的精简系统或者你只是临时搭个测试库二进制包是唯一现实的选择。这个i686包还有个隐藏好处它能在 64 位系统上以 32 位模式运行前提是系统装了 32 位兼容库glibc.i686、libstdc.i686。有些国产 Linux 默认不装 32 位库需要手动补。3. 从解压到能连上初始化、配置和启动的完整命令链3.1 创建 mysql 用户和初始化数据目录MySQL 不允许以 root 身份运行mysqld这是硬性安全策略。先建用户和组。# 创建 mysql 组和用户-r 表示系统用户-s 指定不可登录 shell groupadd mysql useradd -r -g mysql -s /bin/false mysql # 进入 mysql 目录执行初始化脚本 cd /usr/local/mysql ./scripts/mysql_install_db --usermysql --basedir/usr/local/mysql --datadir/usr/local/mysql/datamysql_install_db这个脚本会做几件事创建data目录、生成mysql系统库存用户权限、生成test库、写入初始的rootlocalhost和root主机名账号。注意 4.1 版本的mysql_install_db是 shell 脚本不是后来 5.7 的二进制程序参数写法不一样。参数说明--usermysql指定运行身份--basedir指定安装根目录--datadir指定数据目录。如果datadir路径不存在脚本会尝试创建但父目录权限不对会失败。初始化完成后data目录下会出现ibdata1、ib_logfile0、ib_logfile1和mysql子目录。ibdata1是 InnoDB 的共享表空间4.1 默认存储引擎还是 MyISAM但 InnoDB 已经内置了。3.2 配置文件 my.cnf 的关键参数4.1 版本会按顺序读/etc/my.cnf、/usr/local/mysql/etc/my.cnf、~/.my.cnf。我一般把配置放在/etc/my.cnf内容精简到只写必要项。[mysqld] basedir /usr/local/mysql datadir /usr/local/mysql/data port 3306 socket /tmp/mysql.sock user mysql # 老机器内存有限key_buffer 别设太大 key_buffer 16M max_connections 50 # 4.1 默认字符集是 latin1要存中文必须改 default-character-set utf8key_buffer是 MyISAM 索引缓存4.1 时代大部分表还是 MyISAM这个值直接决定索引查询性能。老机器内存可能只有 256M 或 512M设 16M 到 32M 比较稳妥设太大反而会触发 swap。max_connections默认是 100老机器扛不住降到 50 减少内存占用。default-character-set必须改成utf8否则中文会变成乱码——这是血泪经验4.1 的默认字符集是latin1建库时不指定字符集存进去的中文取出来就是问号。3.3 启动服务并验证连接启动方式有两种直接用mysqld_safe后台拉起或者用support-files/mysql.server脚本。我倾向后者因为它带start、stop、restart子命令管理起来规范。# 复制启动脚本到 init.d 并赋予执行权限 cp /usr/local/mysql/support-files/mysql.server /etc/init.d/mysql chmod x /etc/init.d/mysql # 启动服务 /etc/init.d/mysql start # 验证进程和端口 ps aux | grep mysqld netstat -tlnp | grep 3306 # 用客户端连接 /usr/local/mysql/bin/mysql -u root -p第一次连接时 root 没有密码直接回车即可。连上后立刻设密码SET PASSWORD FOR rootlocalhost PASSWORD(你的密码);。4.1 的密码哈希算法和 5.x 不同PASSWORD()函数生成的是 16 位哈希后来 5.7 改成了 41 位。如果你用现代客户端连 4.1 服务端可能会遇到认证失败因为客户端默认用新算法。解决办法是在客户端加--default-authmysql_old_password或者升级服务端——但升级服务端又受限于 glibc 版本这是个死循环后面避坑章节细说。验证连接时如果报ERROR 2002 (HY000): Cant connect to local MySQL server through socket /tmp/mysql.sock说明服务端没起来或者 socket 路径不对。先看/usr/local/mysql/data/主机名.err这个错误日志里面会写具体原因。常见原因是datadir权限不对——mysql用户对data目录没有写权限mysqld启动到一半就退了。4. 避坑与排查老版本 MySQL 在国产 Linux 上的五个翻车现场4.1 启动报错 FATAL: kernel too old现象执行mysqld或mysql_install_db时直接输出FATAL: kernel too old进程退出。原因这个二进制包编译时假设内核版本不低于 2.4但目标系统的内核可能更老或者虽然内核版本够但 glibc 的ld.so检测到了不兼容的 ABI。另一种可能是目标系统是 64 位但没装 32 位兼容库ld.so找不到 32 位的libc.so.6。解决先uname -r看内核版本低于 2.4 的基本没救只能换机器。如果是 64 位系统缺 32 位库在 openEuler 或麒麟上执行yum install glibc.i686 libstdc.i686或dnf install glibc.i686。装完后用ldd /usr/local/mysql/bin/mysqld检查依赖是否全部解析输出里出现not found就是还缺库。4.2 中文乱码建库时没指定字符集现象插入中文数据后用SELECT查出来全是???或者乱码方块。原因4.1 的服务端默认字符集是latin1客户端连接时如果没显式指定--default-character-setutf8整个连接链路的字符集都是latin1。中文经过latin1编码再解码必然丢失。解决三个层面都要改。服务端my.cnf里加default-character-setutf8建库时写CREATE DATABASE mydb DEFAULT CHARACTER SET utf8;客户端连接时加--default-character-setutf8。已经建好的库可以用ALTER DATABASE mydb DEFAULT CHARACTER SET utf8;改默认字符集但已有表的字符集不会自动变需要ALTER TABLE ... CONVERT TO CHARACTER SET utf8;逐表转换。转换前务必备份这个操作不可逆。4.3 客户端连不上socket 路径和 TCP 端口的混淆现象mysql -u root -p报ERROR 2002但netstat显示 3306 端口在监听。原因MySQL 客户端默认优先走 Unix socket 连接而不是 TCP。如果my.cnf里socket指定的路径和客户端默认查找的路径不一致就会连不上。4.1 客户端默认找/tmp/mysql.sock但有些发行版的my.cnf把 socket 放在/var/lib/mysql/mysql.sock。解决要么在客户端连接时显式指定-S /tmp/mysql.sock要么在my.cnf的[client]段也写上socket /tmp/mysql.sock让服务端和客户端用同一个路径。如果走 TCP 连接加-h 127.0.0.1强制走网络但 4.1 的root账号默认只允许localhost通过 socket 登录TCP 登录需要额外授权root127.0.0.1。4.4 内存不足导致 mysqld 被 OOM Killer 杀掉现象服务运行一段时间后突然断开ps里找不到mysqld进程系统日志/var/log/messages里有Out of memory: Kill process mysqld。原因老机器内存小key_buffer、innodb_buffer_pool_size、max_connections加起来超过了物理内存内核的 OOM Killer 会挑占用最大的进程杀掉。4.1 默认的innodb_buffer_pool_size是 8M不算大但max_connections默认 100每个连接都要分配线程栈和排序缓冲区累积起来很可观。解决把max_connections降到 30 到 50key_buffer控制在 16M 以内sort_buffer_size和read_buffer_size显式设成 256K 或 512K。如果业务确实需要更多连接考虑在前面加个连接池或者换台内存更大的机器。另外可以给mysqld进程设oom_score_adj为 -1000降低被杀的优先级但这只是权宜之计。4.5 用现代客户端连 4.1 服务端认证失败现象用 MySQL 5.7 或 8.0 的客户端连 4.1 服务端报Client does not support authentication protocol requested by server。原因4.1 用的是旧版密码哈希算法16 位5.7 之后的客户端默认用新版算法41 位两者不兼容。服务端说“我只会旧算法”客户端说“我只会新算法”握手就失败了。解决在客户端连接参数里加--default-authmysql_old_password让客户端降级用旧算法。如果客户端版本太新已经移除了旧算法支持MySQL 8.0 客户端就移除了那就只能用 4.1 自带的mysql客户端或者装一个 5.6 版本的客户端作为桥梁。这也是为什么我不建议在同一个环境里混用不同大版本的 MySQL 客户端和服务端——认证协议、字符集、SQL 语法都可能对不上。5. 让这套老环境多撑几年备份策略、字符集统一和迁移判断5.1 用 mysqldump 做逻辑备份的固定套路4.1 自带的mysqldump功能有限但做基础逻辑备份够用。我一般写个脚本每天凌晨跑一次保留最近 7 天。#!/bin/bash # 备份脚本每天全量导出按日期命名 BACKUP_DIR/backup/mysql DATE$(date %Y%m%d) MYSQL_BIN/usr/local/mysql/bin mkdir -p $BACKUP_DIR # --opt 启用快速导出--single-transaction 对 InnoDB 表做一致性快照 $MYSQL_BIN/mysqldump -u root -p你的密码 \ --opt --single-transaction --default-character-setutf8 \ --all-databases $BACKUP_DIR/all_$DATE.sql # 删除 7 天前的备份 find $BACKUP_DIR -name all_*.sql -mtime 7 -delete--opt是个组合参数等价于开启--quick、--add-drop-table、--extended-insert等能显著加快导出速度。--single-transaction只对 InnoDB 有效它通过启动一个事务来保证导出期间数据一致不会锁表。但 4.1 里很多表还是 MyISAMMyISAM 不支持事务导出时还是会加读锁。如果业务对锁敏感只能在低峰期跑备份。恢复时用mysql -u root -p all_20250101.sql。注意 4.1 的mysqldump导出的 SQL 里可能包含/*!40101 SET ... */这种版本注释现代 MySQL 能识别并忽略但反过来现代mysqldump导出的文件拿到 4.1 上恢复可能因为语法太新而报错。跨版本迁移时导出方和导入方的版本差距最好不超过两个大版本。5.2 字符集统一从建库到连接的全链路检查字符集问题在老系统里是玄学同一个库用不同客户端连查出来的中文可能一个正常一个乱码。根因是字符集在服务端、库、表、列、连接五个层面各有一套设置任何一层不一致都会出问题。排查时按这个顺序查检查项命令期望值服务端默认字符集SHOW VARIABLES LIKE character_set_server;utf8客户端连接字符集SHOW VARIABLES LIKE character_set_client;utf8连接结果字符集SHOW VARIABLES LIKE character_set_results;utf8数据库字符集SHOW CREATE DATABASE mydb;DEFAULT CHARSETutf8表字符集SHOW CREATE TABLE mytable;DEFAULT CHARSETutf8如果character_set_client是latin1说明客户端连接时没指定字符集。在my.cnf的[client]段加default-character-setutf8能解决大部分情况。已经存进去的乱码数据没法自动修复只能重新导入正确编码的数据。5.3 什么时候该放弃 4.1 换新版本4.1 是 2004 年的版本距今超过 20 年。它没有存储过程、没有触发器、没有视图、没有information_schema只有SHOW命令、没有utf8mb4存不了 emoji、没有InnoDB的行锁优化。如果你的业务开始需要这些特性或者数据量超过 10GB 导致 MyISAM 表锁成为瓶颈就该考虑迁移了。迁移的难点不在数据本身而在 glibc 依赖链。新版本 MySQL 需要 glibc 2.17 以上而老机器可能跑着 glibc 2.3 的系统。升级 glibc 是高风险操作搞不好整个系统都起不来。我的建议是如果机器还能换直接换一台跑现代 Linux 的新机器用mysqldump把数据导过去如果机器不能换比如工控设备绑定硬件那就维持 4.1但把数据量控制在单表 500 万行以内定期做OPTIMIZE TABLE减少碎片。我自己的习惯是接手任何老 MySQL 环境第一件事是mysqldump全量备份第二件事是记录SHOW VARIABLES的所有输出第三件事是在测试环境复现一遍启动流程。这三件事做完后面无论出什么幺蛾子都有后悔药可吃。希望帮到你。本文还有配套的精品资源点击获取 老i686机器上部署MySQL 4.1.18：二进制tar包实战指南
简介这份资源是 MySQL 4.1.18 的 Linux 二进制安装包面向需要在 PC 架构 Linux 系统上搭建关系型数据库的初学者与小型项目开发者。它基于 GNU 工具链并依赖 glibc23 库解压后即可按官方文档完成配置与安装省去自行编译的繁琐适合用作数据库管理入门、SQL 基础练习或轻量级应用后台的实践环境。压缩包共 1269 个文件约 24.48MB内含可执行程序、测试用例、配置模板与文档手册等多类内容result、test 等文件对应功能验证与回归测试h、inc 等为开发头文件cnf、cfg 提供配置样例readme、txt 则记录安装与使用说明目录结构完整便于按模块查阅。目前已有 131 人学习下载。通过该包读者可实际运行 mysqld、mysqladmin、mysqldump 等工具熟悉 root 账户初始化、权限分配与数据备份流程并借助自带测试脚本理解索引、视图、触发器和存储过程等基础特性为后续版本升级与运维打下扎实根基。1. 老 i686 机器上跑 MySQL这个 tar 包到底解决什么问题手里有一台还在服役的 32 位 x86 老机器或者一个跑着老版本国产 Linux 的隔离环境想装个 MySQL 存点业务数据结果mysql官网下载页翻到底也找不到能用的二进制包——这个场景我遇到过不止一次。mysql-standard-4.1.18-pc-linux-gnu-i686-glibc23.tar就是为这种局面准备的它是 MySQL 4.1.18 官方编译好的 32 位 Linux 二进制发行包i686说明目标 CPU 是 32 位 x86 架构glibc23说明它链接的是 glibc 2.3 时代的 C 运行库tar说明它是个解压即用的绿色包不需要rpm或apt参与。它解决的核心问题是在没有包管理器、没有编译工具链、甚至没有网络的老环境里把一套能跑的 MySQL 服务端和客户端落到磁盘上。适合谁适合维护老旧工控机、内网隔离设备、教学实验环境的运维和嵌入式工程师。不适合谁不适合追求新特性、需要 JSON 字段或窗口函数的生产系统——4.1 这个版本连存储过程都还没有。2. 拆开这个 tar 包目录结构、依赖链和选型判断2.1 解压后你会看到什么先把包解开别急着初始化。用tar -zxvf解到/usr/local下这是老版本 MySQL 二进制包的惯例路径。# 解压到 /usr/local注意 -C 指定目标目录 tar -zxvf mysql-standard-4.1.18-pc-linux-gnu-i686-glibc23.tar -C /usr/local # 解压后会得到一个长名字目录改短方便后续引用 cd /usr/local mv mysql-standard-4.1.18-pc-linux-gnu-i686-glibc23 mysql解压完ls /usr/local/mysql你会看到几个关键目录bin放mysqld、mysql、mysqladmin这些可执行文件scripts放mysql_install_db初始化脚本share放错误信息文件和字符集support-files放启动脚本模板和示例配置。没有data目录因为数据目录要你自己初始化生成。这个结构和现代 MySQL 8.x 的 tar 包逻辑一致只是少了lib下的插件目录。参数说明-z表示用 gzip 解压-x是提取-v显示过程-f指定文件名。顺序上-f必须紧跟文件名写成tar -zxvf file.tar没问题但tar -zxfv file.tar在某些老 tar 上会报错。如果目标机器连tar都没有热词里有人搜「linux没有tar命令」那得先想办法把tar二进制弄进去或者用busybox tar替代。2.2 glibc23 这个标签意味着什么glibc23不是随便写的。它表示这个二进制包在编译时链接的是 glibc 2.3.x 系列。glibc 是 Linux 上最底层的 C 库几乎所有用户态程序都依赖它。二进制程序在运行时需要找到对应版本的libc.so.6如果目标系统的 glibc 版本低于编译时的版本程序会直接报FATAL: kernel too old或者version GLIBC_2.3 not found。这里有个反直觉的点glibc 版本号不是越高越好。高版本 glibc 编译出来的程序拿到低版本系统上跑不了反过来低版本编译的程序在高版本系统上通常能跑。所以glibc23这个包的可移植性其实不错——只要目标系统的 glibc 不低于 2.3基本都能启动。现代发行版比如 openEuler、麒麟 V10 的 glibc 都在 2.28 以上跑这个包没问题。但要注意热词里提到的fatal glibc error: cpu does not support x86-64-v2——那是 64 位系统上 CPU 指令集的问题和这个 32 位包无关别混为一谈。2.3 为什么选二进制包而不是源码编译在老机器上编译 MySQL 源码是件痛苦的事。4.1 时代的源码编译需要gcc、make、ncurses、openssl一堆依赖编译一次动辄半小时以上中间还可能因为缺少某个头文件中断。二进制包的优势是解压即用不依赖编译工具链不挑内核小版本。代价是你没法针对特定 CPU 做指令集优化也没法裁剪不需要的存储引擎。我一般会这样判断如果目标机器有完整的开发工具链且 CPU 性能尚可源码编译能拿到更好的性能如果目标机器是个连gcc都没装的精简系统或者你只是临时搭个测试库二进制包是唯一现实的选择。这个i686包还有个隐藏好处它能在 64 位系统上以 32 位模式运行前提是系统装了 32 位兼容库glibc.i686、libstdc.i686。有些国产 Linux 默认不装 32 位库需要手动补。3. 从解压到能连上初始化、配置和启动的完整命令链3.1 创建 mysql 用户和初始化数据目录MySQL 不允许以 root 身份运行mysqld这是硬性安全策略。先建用户和组。# 创建 mysql 组和用户-r 表示系统用户-s 指定不可登录 shell groupadd mysql useradd -r -g mysql -s /bin/false mysql # 进入 mysql 目录执行初始化脚本 cd /usr/local/mysql ./scripts/mysql_install_db --usermysql --basedir/usr/local/mysql --datadir/usr/local/mysql/datamysql_install_db这个脚本会做几件事创建data目录、生成mysql系统库存用户权限、生成test库、写入初始的rootlocalhost和root主机名账号。注意 4.1 版本的mysql_install_db是 shell 脚本不是后来 5.7 的二进制程序参数写法不一样。参数说明--usermysql指定运行身份--basedir指定安装根目录--datadir指定数据目录。如果datadir路径不存在脚本会尝试创建但父目录权限不对会失败。初始化完成后data目录下会出现ibdata1、ib_logfile0、ib_logfile1和mysql子目录。ibdata1是 InnoDB 的共享表空间4.1 默认存储引擎还是 MyISAM但 InnoDB 已经内置了。3.2 配置文件 my.cnf 的关键参数4.1 版本会按顺序读/etc/my.cnf、/usr/local/mysql/etc/my.cnf、~/.my.cnf。我一般把配置放在/etc/my.cnf内容精简到只写必要项。[mysqld] basedir /usr/local/mysql datadir /usr/local/mysql/data port 3306 socket /tmp/mysql.sock user mysql # 老机器内存有限key_buffer 别设太大 key_buffer 16M max_connections 50 # 4.1 默认字符集是 latin1要存中文必须改 default-character-set utf8key_buffer是 MyISAM 索引缓存4.1 时代大部分表还是 MyISAM这个值直接决定索引查询性能。老机器内存可能只有 256M 或 512M设 16M 到 32M 比较稳妥设太大反而会触发 swap。max_connections默认是 100老机器扛不住降到 50 减少内存占用。default-character-set必须改成utf8否则中文会变成乱码——这是血泪经验4.1 的默认字符集是latin1建库时不指定字符集存进去的中文取出来就是问号。3.3 启动服务并验证连接启动方式有两种直接用mysqld_safe后台拉起或者用support-files/mysql.server脚本。我倾向后者因为它带start、stop、restart子命令管理起来规范。# 复制启动脚本到 init.d 并赋予执行权限 cp /usr/local/mysql/support-files/mysql.server /etc/init.d/mysql chmod x /etc/init.d/mysql # 启动服务 /etc/init.d/mysql start # 验证进程和端口 ps aux | grep mysqld netstat -tlnp | grep 3306 # 用客户端连接 /usr/local/mysql/bin/mysql -u root -p第一次连接时 root 没有密码直接回车即可。连上后立刻设密码SET PASSWORD FOR rootlocalhost PASSWORD(你的密码);。4.1 的密码哈希算法和 5.x 不同PASSWORD()函数生成的是 16 位哈希后来 5.7 改成了 41 位。如果你用现代客户端连 4.1 服务端可能会遇到认证失败因为客户端默认用新算法。解决办法是在客户端加--default-authmysql_old_password或者升级服务端——但升级服务端又受限于 glibc 版本这是个死循环后面避坑章节细说。验证连接时如果报ERROR 2002 (HY000): Cant connect to local MySQL server through socket /tmp/mysql.sock说明服务端没起来或者 socket 路径不对。先看/usr/local/mysql/data/主机名.err这个错误日志里面会写具体原因。常见原因是datadir权限不对——mysql用户对data目录没有写权限mysqld启动到一半就退了。4. 避坑与排查老版本 MySQL 在国产 Linux 上的五个翻车现场4.1 启动报错 FATAL: kernel too old现象执行mysqld或mysql_install_db时直接输出FATAL: kernel too old进程退出。原因这个二进制包编译时假设内核版本不低于 2.4但目标系统的内核可能更老或者虽然内核版本够但 glibc 的ld.so检测到了不兼容的 ABI。另一种可能是目标系统是 64 位但没装 32 位兼容库ld.so找不到 32 位的libc.so.6。解决先uname -r看内核版本低于 2.4 的基本没救只能换机器。如果是 64 位系统缺 32 位库在 openEuler 或麒麟上执行yum install glibc.i686 libstdc.i686或dnf install glibc.i686。装完后用ldd /usr/local/mysql/bin/mysqld检查依赖是否全部解析输出里出现not found就是还缺库。4.2 中文乱码建库时没指定字符集现象插入中文数据后用SELECT查出来全是???或者乱码方块。原因4.1 的服务端默认字符集是latin1客户端连接时如果没显式指定--default-character-setutf8整个连接链路的字符集都是latin1。中文经过latin1编码再解码必然丢失。解决三个层面都要改。服务端my.cnf里加default-character-setutf8建库时写CREATE DATABASE mydb DEFAULT CHARACTER SET utf8;客户端连接时加--default-character-setutf8。已经建好的库可以用ALTER DATABASE mydb DEFAULT CHARACTER SET utf8;改默认字符集但已有表的字符集不会自动变需要ALTER TABLE ... CONVERT TO CHARACTER SET utf8;逐表转换。转换前务必备份这个操作不可逆。4.3 客户端连不上socket 路径和 TCP 端口的混淆现象mysql -u root -p报ERROR 2002但netstat显示 3306 端口在监听。原因MySQL 客户端默认优先走 Unix socket 连接而不是 TCP。如果my.cnf里socket指定的路径和客户端默认查找的路径不一致就会连不上。4.1 客户端默认找/tmp/mysql.sock但有些发行版的my.cnf把 socket 放在/var/lib/mysql/mysql.sock。解决要么在客户端连接时显式指定-S /tmp/mysql.sock要么在my.cnf的[client]段也写上socket /tmp/mysql.sock让服务端和客户端用同一个路径。如果走 TCP 连接加-h 127.0.0.1强制走网络但 4.1 的root账号默认只允许localhost通过 socket 登录TCP 登录需要额外授权root127.0.0.1。4.4 内存不足导致 mysqld 被 OOM Killer 杀掉现象服务运行一段时间后突然断开ps里找不到mysqld进程系统日志/var/log/messages里有Out of memory: Kill process mysqld。原因老机器内存小key_buffer、innodb_buffer_pool_size、max_connections加起来超过了物理内存内核的 OOM Killer 会挑占用最大的进程杀掉。4.1 默认的innodb_buffer_pool_size是 8M不算大但max_connections默认 100每个连接都要分配线程栈和排序缓冲区累积起来很可观。解决把max_connections降到 30 到 50key_buffer控制在 16M 以内sort_buffer_size和read_buffer_size显式设成 256K 或 512K。如果业务确实需要更多连接考虑在前面加个连接池或者换台内存更大的机器。另外可以给mysqld进程设oom_score_adj为 -1000降低被杀的优先级但这只是权宜之计。4.5 用现代客户端连 4.1 服务端认证失败现象用 MySQL 5.7 或 8.0 的客户端连 4.1 服务端报Client does not support authentication protocol requested by server。原因4.1 用的是旧版密码哈希算法16 位5.7 之后的客户端默认用新版算法41 位两者不兼容。服务端说“我只会旧算法”客户端说“我只会新算法”握手就失败了。解决在客户端连接参数里加--default-authmysql_old_password让客户端降级用旧算法。如果客户端版本太新已经移除了旧算法支持MySQL 8.0 客户端就移除了那就只能用 4.1 自带的mysql客户端或者装一个 5.6 版本的客户端作为桥梁。这也是为什么我不建议在同一个环境里混用不同大版本的 MySQL 客户端和服务端——认证协议、字符集、SQL 语法都可能对不上。5. 让这套老环境多撑几年备份策略、字符集统一和迁移判断5.1 用 mysqldump 做逻辑备份的固定套路4.1 自带的mysqldump功能有限但做基础逻辑备份够用。我一般写个脚本每天凌晨跑一次保留最近 7 天。#!/bin/bash # 备份脚本每天全量导出按日期命名 BACKUP_DIR/backup/mysql DATE$(date %Y%m%d) MYSQL_BIN/usr/local/mysql/bin mkdir -p $BACKUP_DIR # --opt 启用快速导出--single-transaction 对 InnoDB 表做一致性快照 $MYSQL_BIN/mysqldump -u root -p你的密码 \ --opt --single-transaction --default-character-setutf8 \ --all-databases $BACKUP_DIR/all_$DATE.sql # 删除 7 天前的备份 find $BACKUP_DIR -name all_*.sql -mtime 7 -delete--opt是个组合参数等价于开启--quick、--add-drop-table、--extended-insert等能显著加快导出速度。--single-transaction只对 InnoDB 有效它通过启动一个事务来保证导出期间数据一致不会锁表。但 4.1 里很多表还是 MyISAMMyISAM 不支持事务导出时还是会加读锁。如果业务对锁敏感只能在低峰期跑备份。恢复时用mysql -u root -p all_20250101.sql。注意 4.1 的mysqldump导出的 SQL 里可能包含/*!40101 SET ... */这种版本注释现代 MySQL 能识别并忽略但反过来现代mysqldump导出的文件拿到 4.1 上恢复可能因为语法太新而报错。跨版本迁移时导出方和导入方的版本差距最好不超过两个大版本。5.2 字符集统一从建库到连接的全链路检查字符集问题在老系统里是玄学同一个库用不同客户端连查出来的中文可能一个正常一个乱码。根因是字符集在服务端、库、表、列、连接五个层面各有一套设置任何一层不一致都会出问题。排查时按这个顺序查检查项命令期望值服务端默认字符集SHOW VARIABLES LIKE character_set_server;utf8客户端连接字符集SHOW VARIABLES LIKE character_set_client;utf8连接结果字符集SHOW VARIABLES LIKE character_set_results;utf8数据库字符集SHOW CREATE DATABASE mydb;DEFAULT CHARSETutf8表字符集SHOW CREATE TABLE mytable;DEFAULT CHARSETutf8如果character_set_client是latin1说明客户端连接时没指定字符集。在my.cnf的[client]段加default-character-setutf8能解决大部分情况。已经存进去的乱码数据没法自动修复只能重新导入正确编码的数据。5.3 什么时候该放弃 4.1 换新版本4.1 是 2004 年的版本距今超过 20 年。它没有存储过程、没有触发器、没有视图、没有information_schema只有SHOW命令、没有utf8mb4存不了 emoji、没有InnoDB的行锁优化。如果你的业务开始需要这些特性或者数据量超过 10GB 导致 MyISAM 表锁成为瓶颈就该考虑迁移了。迁移的难点不在数据本身而在 glibc 依赖链。新版本 MySQL 需要 glibc 2.17 以上而老机器可能跑着 glibc 2.3 的系统。升级 glibc 是高风险操作搞不好整个系统都起不来。我的建议是如果机器还能换直接换一台跑现代 Linux 的新机器用mysqldump把数据导过去如果机器不能换比如工控设备绑定硬件那就维持 4.1但把数据量控制在单表 500 万行以内定期做OPTIMIZE TABLE减少碎片。我自己的习惯是接手任何老 MySQL 环境第一件事是mysqldump全量备份第二件事是记录SHOW VARIABLES的所有输出第三件事是在测试环境复现一遍启动流程。这三件事做完后面无论出什么幺蛾子都有后悔药可吃。希望帮到你。本文还有配套的精品资源点击获取