简介一份适用于PC Linux平台的MySQL 4.1.18标准版二进制发布包面向数据库初学者、运维人员以及需要研究早期MySQL架构的开发者。该版本具备基本SQL支持、索引、视图、触发器和存储过程可搭建轻量级教学或测试环境。资源共1269个文件压缩后约24.48MB主体为测试脚本与结果test、result、C语言头文件h、inc、配置与文档cfg、xml、readme、txt并包含mysqld、mysqladmin、mysqldump等服务端和管理工具便于按模块离线查阅。已有132人学习浏览。通过这份包读者既能掌握MySQL 4.1.18的部署与基础管理又可借助内置测试用例和配置样例理解早期版本的工作机制同时mysql_secure_installation、mysql_fix_privilege_tables等脚本也为安全设置与权限修复提供了实操参考适合作为学习旧版MySQL运维细节的素材。1. 这包是给谁的mysql-standard-4.1.18-pc-linux-gnu-i686-glibc23.tar 还在运行的真相我第一次见到mysql-standard-4.1.18-pc-linux-gnu-i686-glibc23.tar是在一台几乎没人敢碰的旧服务器上。那套业务系统跑了好几年数据库一直没人动过上面跑的正是一个 MySQL 4.1 的老实例。后来需要把环境复制到另一台机器做验证翻遍安装包才发现当初部署的人留了一个 tar 包就是这个名字。它在讲一件很朴素的事这是一个面向 32 位 x86 Linux、依赖 glibc 2.3 的 MySQL 4.1.18 standard 版官方二进制发行包。不用 configure、不用 make解压、初始化、拉起 mysqld_safe 就能用。这个包能解决的问题非常具体存量老业务不能随便换数据库版本目标机器又是旧 32 位系统既没有源码编译器也没有对应 RPM 依赖tar 包反而是最可靠的上线形态。适合谁读一类是还在维护老系统、三天两头被 MySQL 4.1 的怪脾气折磨的工程师另一类是想在容器或虚拟机里复现老环境、认真研究 4.1 行为边界的开发者。下面所有操作都围绕这个确切的包名展开。2. 解压与布局把现成的 tar 装成 /usr/local/mysql2.1 为什么这种老库更依赖 tar 包而不是 RPM 或源码编译MySQL 4.1 活跃的年代Linux 发行版的包管理远没有今天统一。同一台机器上Red Hat 系用 RPMDebian 系用 dpkgSLES 又有一套自己的规则。一个 RPM 包通常只在某个特定发行版和版本上能装换一台机器就可能出现依赖地狱。而mysql-standard-4.1.18-pc-linux-gnu-i686-glibc23.tar这类官方 tar 包的设计目标就是跨发行版它把二进制、库文件、字符集、错误消息、示例配置全部打进一个归档里只要目标系统的 CPU 架构是 i686、glibc 是 2.3.x 或向后兼容的环境解压就能执行。对于存量业务这几乎是唯一不依赖厂商仓库、不受系统升级影响的交付方式。源码编译在当时的场景下更不现实。4.1 年代的编译链很挑GCC 版本、glibc 版本、甚至 make 的版本不对编译出来的 mysqld 跑起来就有各种隐性故障。更重要的是存量数据文件是二进制格式从 4.1 的 MyISAM 表文件到授权表结构都和生产环境当时的编译选项强相关。稳妥做法永远是找到和生产环境同一系列、同一 CPU 位数的官方预编译包而不是自己重新编译一个。下表是我在选型时通常做的对比交付方式依赖情况部署速度与存量数据兼容性适用场景RPM 包依赖发行版库和 glibc 版本快但常被依赖卡住取决于仓库编译选项新装且发行版匹配源码编译依赖工具链时间长慢需手动配置需完全复刻编译参数老系统无现成二进制官方 tar 包只依赖内核和 32 位加载器最快解压即用最接近官方默认布局复现老环境、存量迁移所以标题里这个 tar 包的核心价值不在“新”而在“准”它对应一个特定的官方编译版本行为边界是固定的遇到问题可以通过版本号精确反查。2.2 校验、解压、建软链最小动作清单拿到包之后第一步不是急着解压而是先确认这个包没有被截断。常见做法是用文件大小和 MD5 校验值做比对本地没有记录的话至少用file命令确认格式再用tar -tzf列出包内文件看看是不是 MySQL 的目录结构。# 1. 确认文件格式是不是 gzip 压缩的 tar file mysql-standard-4.1.18-pc-linux-gnu-i686-glibc23.tar # 2. 不解压直接列出包内顶层内容确认是完整目录 tar -tzf mysql-standard-4.1.18-pc-linux-gnu-i686-glibc23.tar | head -20 # 3. 解压到 /usr/local通常保留官方目录名 tar -zxvf mysql-standard-4.1.18-pc-linux-gnu-i686-glibc23.tar -C /usr/local # 4. 建一个不带版本号的软链避免后续脚本反复改路径 ln -s /usr/local/mysql-standard-4.1.18-pc-linux-gnu-i686-glibc23 /usr/local/mysql # 5. 确认解压结果和二进制架构 ls -F /usr/local/mysql file /usr/local/mysql/bin/mysqld这里解释一下每个命令的意图。file的输出如果包含gzip compressed data说明下载的确实是压缩后的 tar 包如果提示HTML document之类八成拿到的是某个下载页面的错误页后面所有步骤都会莫名其妙失败。tar -tzf是花钱最少的安全检查能看到内部路径里有没有bin/mysqld、share/mysql这些关键目录。软链这步容易被忽略但所有配置文件和启动脚本里写死/usr/local/mysql比写一长串版本号目录省心得多后面升级时也只需要换软链指向。最后用file看 mysqld正常输出应该是ELF 32-bit LSB executable, Intel 80386如果看到64-bit字样说明包不对或已经被改动过。2.3 目录里有什么bin、share、support-files 各自承担什么解压后不要急着初始化先花两分钟把目录结构认一遍。这个包解出来通常包含这些目录bin里面是全部可执行文件包括mysqld、mysqld_safe、mysql、mysqladmin、mysqldump、myisamchk、mysql_install_db、resolveip等share下面主要是mysql子目录放着字符集定义、errmsg 错误消息文件、数据字典模板support-files里是 Linux 发行版常用的辅助脚本和示例配置比如mysql.server和若干my-*.cnf模板include和lib是给客户端开发用的头文件与库文件服务端运行时基本用不到。在这些文件里有两点值得注意。一是mysqld和mysqld_safe的关系mysqld是真正的数据库服务进程mysqld_safe是一个包装脚本会检查日志目录、设置 umask、在 mysqld 崩溃时尝试重启所以正式启动一定要走mysqld_safe而不是直接mysqld。二是mysql_install_db这个脚本的位置在不同 4.1 小版本里可能不同有的在bin/下有的在scripts/下如果找不到就全盘 find 一下find /usr/local/mysql -name mysql_install_db -type f如果在执行阶段发现系统缺少 32 位动态库ldd能看到具体缺失项这个放到第 5 章排查部分详细展开。目录布局本身不用记死但要记住一句话老版本 MySQL 对路径非常敏感basedir、datadir、socket 三者必须自洽。基于这一点下一步就该规划数据目录了。3. 初始化与启动用最小 my.cnf 把 mysqld_safe 拉起来3.1 数据目录与 mysql 用户先解决“谁的权限”问题MySQL 4.1 时代的安全意识比今天粗糙得多但有一个习惯是当时就已经确立的不要用 root 用户跑 mysqld。mysqld 一旦被注入或利用漏洞进程权限直接决定攻击者能拿到什么。所以在解压完成后第一件事是创建专用账号并把数据目录的属主交给它。数据目录我一般不会放在安装目录里而是单独放到一个分区或独立目录比如/data/mysql-4.1/data。这样做的原因很实际将来升级时可以直接换软链、保留数据目录不动备份时也只需要针对一个目录做策略避免安装目录被误删时连数据一起带走。# 1. 创建 mysql 系统账号禁止交互登录 useradd -r -s /bin/false -d /data/mysql-4.1 mysql # 2. 创建数据目录并设置属主 mkdir -p /data/mysql-4.1/data chown -R mysql:mysql /data/mysql-4.1 # 3. 安装目录允许 mysql 读和执行但不需要写 chown -R root:root /usr/local/mysql chmod -R 755 /usr/local/mysql这里有个细节安装目录原则上只需要 root 可写mysqld 运行时只读它。数据目录才是 mysql 用户需要完全控制的地方。很多老系统上出问题都是因为直接把整个/usr/local/mysqlchown 给了 mysql后来有人在安装目录里改了文件权限又开始混乱。我习惯把安装目录和数据目录的属主分开能让“程序文件”和“数据文件”的边界清楚很多。3.2 最小 my.cnf4.1 时代的关键参数与命名差异4.1 的配置参数命名和 5.x、8.x 有差异网上搜到的现代教程参数不能直接抄。比如字符集参数在 4.1 叫default-character-set到 5.0 之后才改成character_set_server表缓存参数在 4.1 叫table_cache到 5.1 后才改成table_open_cache。一个最小可用的配置文件长这样[mysqld] basedir /usr/local/mysql datadir /data/mysql-4.1/data socket /tmp/mysql.sock pid-file /data/mysql-4.1/data/mysql.pid port 3306 user mysql skip-networking 0 default-character-set utf8 max_connections 100 key_buffer_size 64M lower_case_table_names 0 [client] socket /tmp/mysql.sock default-character-set utf8对 4.1 来说basedir和datadir是最重要的两个参数mysqld_safe启动时会读取它们决定去哪找二进制、去哪找数据文件。socket参数在[mysqld]和[client]两段都要写并且必须一致否则服务端在/tmp/mysql.sock监听客户端默认去/var/lib/mysql/mysql.sock找结果就是经典的 “Cant connect through socket” 报错。lower_case_table_names在 Linux 上默认是 0即表名区分大小写如果你的应用是从 Windows 迁过来的建议改成 1让所有表名统一转成小写否则换个平台就可能出现Table db.Table doesnt exist。改这个参数有个前提必须在初始化数据目录之前就决定好因为它影响表名存储的底层行为中途改会有风险。# 配置文件放到 /etc/my.cnf这是 4.1 默认查找顺序里优先级最高的位置 cp /usr/local/mysql/support-files/my-medium.cnf /etc/my.cnf # 然后按上面的内容手工修改关键项 vim /etc/my.cnfmy-medium.cnf是官方给出的中配模板比空配置文件多了很多注释项初学者直接改它比从零写更不容易漏参数。当然模板里的很多项被注释掉了只需放开需要的几项即可。3.3 mysql_install_db 初始化授权表这一步是新手最容易卡住的地方。mysql_install_db的作用不是建数据库而是在指定的datadir下创建 MySQL 自带的系统库mysql、test库以及授权表、帮助表等基础数据。可以理解为给一台空机器“装操作系统”。4.1 的默认行为是如果不指定--datadir它会在basedir/var下建目录而不是我们前面规划的/data/mysql-4.1/data。所以这条命令务必显式传参。cd /usr/local/mysql # 在 4.1 里脚本可能不在 bin 下用 find 找到后执行 ./bin/mysql_install_db \ --basedir/usr/local/mysql \ --datadir/data/mysql-4.1/data \ --usermysql执行成功时最后一行通常会出现类似Starting mysqld daemon with databases from /data/mysql-4.1/data的信息然后脚本自动退出。如果中途报错最常见的是Cant create/write to file /data/mysql-4.1/data/mysql/user.MYI这几乎都是数据目录属主不对mysql 用户没有写权限。解决方式就是回到 3.1 节重新chown -R mysql:mysql数据目录。这个脚本实际做的事是从share/mysql目录下的模板文件向新的数据目录灌入系统库和默认账号初始状态是存在 root 空密码账号和匿名账号的具体处理放到第 4 章。3.4 mysqld_safe 启动、探活与关闭初始化成功后就可以启动了。我一般用mysqld_safe而不是直接跑mysqld因为mysqld_safe会做几件很实际的事把错误输出重定向到错误日志文件、以指定用户身份运行、在 mysqld 意外退出后自动再次拉起。这个包装对老版本尤其重要4.1 的 mysqld 一崩就是真崩没有 wrapper 的自动重启半夜出问题就得手工去拉。# 启动 /usr/local/mysql/bin/mysqld_safe --defaults-file/etc/my.cnf --usermysql # 探活 /usr/local/mysql/bin/mysqladmin ping # 看错误日志确认确实起来了 tail -n 30 /data/mysql-4.1/data/*.err日志里如果出现mysqld started、ready for connections这两行说明进程已经正常监听端口和 socket。注意 4.1 的错误日志默认叫hostname.err存放在datadir下名字不固定所以用通配符*.err看最省事。关闭服务不要直接 kill 进程正确姿势是用mysqladmin/usr/local/mysql/bin/mysqladmin -uroot -p shutdown这个命令会走正常的关停流程刷新脏页、关闭连接、清理临时文件最后进程自己退出。直接kill -9对 MyISAM 表容易留下未刷盘的数据页后续启动时 myisamchk 不一定能自动修复所有问题。初次关闭时 root 大概率还是空密码-p后直接回车即可如果已经设置过密码就输入对应密码。4. 首次登录与账号加固空密码 root 不是能用的状态4.1 第一次连进去确认版本、引擎、日志位置服务起来之后用客户端连接本机实例。注意 4.1 的mysql客户端默认使用/tmp/mysql.sock如果配置文件的 socket 路径与之不同需要显式用-S指定。/usr/local/mysql/bin/mysql -uroot -S /tmp/mysql.sock mysql SELECT VERSION(); mysql SHOW VARIABLES LIKE have_innodb; mysql SHOW VARIABLES LIKE character_set_server;SELECT VERSION()应该返回4.1.18或者带小版本号。have_innodb用来确认 InnoDB 是否被编译进这个包standard 版的编译开关和 max 版不同如果结果是NO说明建表默认只能用 MyISAM后面设计表结构时就不要写ENGINEInnoDB否则会报 unknown storage engine。这对老系统很重要因为很多 4.1 时代的业务表确实是 MyISAM甚至把 InnoDB 功能当成“高级版”才有。character_set_server用来验证default-character-set utf8是否生效如果仍是默认的latin1说明配置文件没被正确读取需要确认/etc/my.cnf的路径和权限。4.2 设置 root 密码新哈希与 OLD_PASSWORD 的差异这一步是整个初始化里最有“历史感”的地方。MySQL 4.1 在认证协议上经历了一次重要升级旧协议用 16 字节的密码哈希新协议用 20 字节的 SHA1 哈希。4.1 之后的服务器默认使用新协议但很多 4.1 时代的老客户端比如 3.23、4.0 时代的程序只认旧协议。如果你的存量应用里有这种老古董客户端设置 root 密码时就要考虑用哪种哈希。-- 默认做法使用新协议哈希适合 4.1 及更新客户端 SET PASSWORD FOR rootlocalhost PASSWORD(你的强密码); -- 如果存在 4.0 及更早的老客户端必须用旧哈希 SET PASSWORD FOR rootlocalhost OLD_PASSWORD(你的强密码);两段代码的区别只有一个函数PASSWORD()生成新哈希OLD_PASSWORD()生成老哈希。从运维角度我建议新客户端环境一律用PASSWORD()因为老哈希本身就是脆弱点只有确认业务里有无法升级的老连接代码才考虑OLD_PASSWORD()。另外localhost和127.0.0.1在授权表里是两个独立的 host 条目只改rootlocalhost的话从 127.0.0.1 连接的 root 还是空密码所以两条都要处理。SET PASSWORD FOR root127.0.0.1 PASSWORD(你的强密码); FLUSH PRIVILEGES;FLUSH PRIVILEGES的作用是让授权表的改动立即生效。虽然 4.1 在大部分账号操作后会自动重载但显式执行一次能避免“改了没生效”的错觉尤其是手工DELETE授权表记录后这个动作是必须的。4.3 删除匿名账号并重建业务账号一条 GRANT 搞定初始化后的 system 库里除了 root还默认存在空用户名的匿名账号。这类账号意味着任何本地用户只要不指定用户名就能连进数据库且权限可能超出预期。老版本安装指南从不提这个事但现在绝不能留着。删除匿名账号最通用的方式是操作授权表SELECT user, host FROM mysql.user; DELETE FROM mysql.user WHERE user; FLUSH PRIVILEGES;之后创建一个业务账号。4.1 的GRANT语句可以顺带完成“建账号 授权”两件事不需要先CREATE USERGRANT ALL PRIVILEGES ON 业务库名.* TO app192.168.1.% IDENTIFIED BY 业务密码; FLUSH PRIVILEGES;192.168.1.%表示只允许内网某个网段的来源连接这是 4.1 时代最容易做到的访问控制。不要用%通配全部来源除非你真的需要。授权完成后建议重新登录验证一次先exit退出再用新账号连接并执行SHOW DATABASES;确认只能看到授权的库。这里有个 4.1 特有的行为差异要提醒4.1 没有 MySQL 5.0 之后才引入的严格 SQL 模式写入超长字符串时是截断而不是报错所以业务逻辑不能依赖“数据库会报错”来发现问题应用层校验必须做在前面。5. 避坑实录4.1.18 在陌生机器上常见的 5 个翻车点5.1 报错“No such file or directory”却不是文件不存在现象执行/usr/local/mysql/bin/mysqld_safe或直接跑./bin/mysqld终端返回-bash: ./mysqld: No such file or directory。第一反应是去看文件在不在ls一查文件明明就在权限也是 755。这就是老 32 位包在 64 位系统上最常见的翻车现场。原因这个包是 i686 架构系统要运行它必须能加载 32 位动态链接器/lib/ld-linux.so.2。如果系统缺少 IA32 兼容库内核执行该 ELF 文件时找不到加载器bash 就会把这个情况描述成“文件不存在”其实文件在缺的是运行时环境。解决在 Debian/Ubuntu 系安装libc6-i386在 CentOS/RHEL 系安装glibc.i686。装完后再用ldd bin/mysqld复查缺什么库一目了然比如常见的libstdc.so.6。这类依赖属于系统级组件装完不需要重跑初始化直接再启动即可。这个坑的迷惑性极强我第一次遇到时查了半小时文件权限。5.2 mysql_install_db 说 host 无法解析现象执行mysql_install_db时终端输出Neither host 某主机名 nor localhost could be looked up with /usr/local/mysql/bin/resolveip然后初始化终止。这台机器的主机名明明能正常显示网络也是通的。原因mysql_install_db脚本内部会调用resolveip去解析当前主机名。4.1 年代的系统里/etc/hosts往往只写了127.0.0.1 localhost没写“主机名 - 本机 IP”的记录解析就会失败。这跟 DNS 没关系纯属本地 hosts 文件不完整。解决编辑/etc/hosts在127.0.0.1那行末尾加上当前主机名或者单独加一行本机IP 主机名重新执行初始化即可。这个坑特别容易发生在克隆虚拟机之后因为克隆会改主机名但 hosts 不会自动跟着改。后续如果 mysqld 启动时报类似的主机名解析错误也是同样的处理方式。5.3 socket 不一致导致客户端连不上现象mysqld_safe启动后日志显示ready for connections但客户端执行mysql -uroot -p报ERROR 2002 (HY000): Cant connect to local MySQL server through socket /tmp/mysql.sock。进程明明活着日志也说正常为什么连不上。原因服务端把 socket 文件创建在了datadir下客户端默认却去/tmp/mysql.sock找。4.1 对 socket 路径的处理在不同发行版模板里并不统一有的默认编译路径是/tmp/mysql.sock有的则是/var/lib/mysql/mysql.sock而配置文件里如果不显式写 socket两端就会各自用默认值正好不一致。解决在/etc/my.cnf的[mysqld]和[client]两段都显式写socket /tmp/mysql.sock然后重启 mysqld再用mysqladmin ping验证。如果客户端这边不想依赖配置文件也可以直接mysql -S /tmp/mysql.sock硬指定。记住一个原则老版本 MySQL 的 socket 路径全靠自己管谁都不帮你自动协调。5.4 改完密码后本地登录仍 Access denied现象成功执行第 4 章的密码设置后退出再用mysql -uroot -p登录输入密码却报Access denied。用空密码反而能进去或者怎么试都进不去非常诡异。原因最常见的情况是授权表里存在两条匹配记录一条是刚设过密码的rootlocalhost另一条是空密码的root127.0.0.1或匿名账号。客户端连接时MySQL 按“主机最具体优先”的规则匹配授权记录本地连接可能落到了空密码那条上或者匿名账号把请求接走了导致你输入新密码时校验的对象根本不是你以为的那个账户。解决登录进去执行SELECT user, host, password FROM mysql.user;把 rootlocalhost 和 root127.0.0.1 的密码都设成一致然后删掉所有User的匿名记录最后FLUSH PRIVILEGES。之后用mysql -uroot -p -h 127.0.0.1和mysql -uroot -p -h localhost分别验证一遍两条路径都能进才算干净。这个问题至今还困扰着不少老系统维护者本质是授权表的记录组合比想象得多。5.5 mysqld_safe 拉起后立刻消失现象执行mysqld_safe 后过几秒进程就退了日志没有任何明显的ready for connections行甚至错误日志只有一两行就中断。原因多数跟权限或日志路径有关。mysqld_safe启动时会尝试写错误日志如果log-error指定的目录不存在或对 mysql 用户不可写wrapper 会直接放弃启动。另一种常见情况是datadir下出现了 root 拥有的临时文件mysql 用户无法清理。解决先看错误日志的最后几行如果是权限问题chown -R mysql:mysql数据目录并确保日志轮转目录的属主也是 mysql。如果日志里出现的是Cant start server: Bind on unix socket: Permission denied则检查/tmp目录权限或换一个 socket 路径。如果日志完全没有可以手动带--console参数前台运行一次让错误直接打到终端比猜原因快得多。这个手段放在今天依然是最有效的排错方式老 MySQL 不会撒谎它只是把真相写在你没看的地方。6. 进阶让它安分地再跑几年备份、权限与最小暴露面到这一步一个 4.1.18 实例已经能稳定跑起来了。但如果它要承担真实业务还有三件事值得马上做。第一是备份习惯。4.1 时代的 mysqldump 还没有今天那么多花哨选项最可靠的备份方式是全库锁定后导出/usr/local/mysql/bin/mysqldump \ -uroot -p \ --all-databases \ --lock-all-tables \ --add-drop-table \ | gzip /backup/mysql-$(date %F).sql.gz--lock-all-tables对 MyISAM 是必须的它在整个 dump 过程中全局加读锁保证备份文件是某一时刻的一致性快照。--single-transaction对 InnoDB 才有效而 standard 包多数场景跑的是 MyISAM所以不要盲目抄现代备份脚本。把这条命令写进 cron每天凌晨执行一次保留最近 7 份这是老库最基本的后悔药。第二是网络暴露面。4.1.18 的认证协议和加密强度放到今天已经明显过时绝对不要在公网环境监听 3306。如果业务必须走 TCP 访问至少用防火墙把来源限制在可信网段如果只有本机应用连接直接在[mysqld]里开skip-networking让数据库只走 socket这是最彻底的隔离手段。我见过太多老库出事不是被复杂攻击打穿而是因为 3306 端口大敞着被扫到之后用弱口令进的。第三是升级路径。很多人以为 4.1 的库只能永远留在 4.1实际上官方支持了 4.1 到 5.0、5.0 到 5.1 的连续升级路线。真要做升级流程是先在备用机器上把 4.1 的备份恢复出来再跑新版本源码包里的mysql_upgrade脚本逐步升全程不要跳版本。我的个人习惯是凡是接触 4.1 这种老库任何操作之前先做全量备份能不动授权表就不动要动就一条一条执行并立刻验证遇到看不懂的报错先看错误日志而不是盲目重启。这些习惯让我少熬了很多夜。希望帮到你。本文还有配套的精品资源点击获取