简介mysql-4.1.11.tar.gz是MySQL 4.1.11数据库系统的完整源码包采用tar与gzip压缩适用于需要在Linux/Unix环境下部署、编译或研究早期MySQL架构的开发者与运维人员。资源共包含4541个文件压缩包大小约21.82MB目录结构完整主要文件类型包括C/C源代码.c、.h、.cpp、.cc、.hpp、构建配置脚本.ac、.am、.in、.sh、.configure、测试用例与结果文件.test、.result、.tcl、.testout以及Java、XML、HTML文档和平台相关编译辅助文件可满足从源码编译到功能验证的需求。目前已吸引197人浏览学习具有一定参考价值。该版本虽较为陈旧但有利于理解数据库内核的基础实现也可用于兼容特定遗留业务系统。通过分析该源码包可深入掌握MySQL 4.1.11的模块划分、客户端与服务端实现、存储引擎接口以及多种Unix/Windows构建方式同时附带的测试集和回归结果也为数据库内核学习或旧系统排错提供了真切素材。1. mysql-4.1.11.tar.gz一份值得回炉的“上古”数据库源码mysql-4.1.11.tar.gz 这个包名对现在的开发者来说有点陌生但在 2005 年前后它是很多网站和业务系统的底层数据库。4.1 版本是 MySQL 历史上一个分水岭它引入了子查询、视图勉强能用、预处理语句PREPARE/EXECUTE以及真正的 InnoDB 事务支持同时字符集体系从 latin1 一家独大变成了可切换的多字符集模型。如果你做老系统兼容、二进制安全比对、或者想研究 InnoDB 早期 B-tree 实现这份源码比文档值钱得多——它没有后来 5.7/8.0 里那层厚厚的抽象直接读代码就能看到索引页分裂和锁等待的真实逻辑。适合三类人被老业务系统锁死的运维、研究存储引擎实现的开发者、以及想做源码级定制的人。这篇笔记我把编译、初始化、避坑和数据迁移都过了一遍你照着做能少走很多弯路。2. 源码包解剖目录结构与老版本依赖的编译器生态2.1 解包后先看什么configure 脚本与关键源码目录拿到 mysql-4.1.11.tar.gz 先别急着 ./configure先解压并观察目录结构。我一般会执行tar -tzf mysql-4.1.11.tar.gz | head -40输出里你会看到 configure、configure.in、configure.ac、Makefile.am、sql/、mysys/、myisam/、innobase/ 这些路径。和现代 MySQL 源码相比4.1 没有 CMakeLists.txt——它是纯 autotools 体系这意味着你必须在编译环境里装好 autoconf、automake、libtool否则 configure 脚本都没法生成。tar -xzf mysql-4.1.11.tar.gz cd mysql-4.1.11 ls -F | grep /重点关注三个目录sql/核心服务端逻辑包括词法解析、执行计划生成、SQL 命令分发。4.1 的优化器还非常原始表连接顺序基本靠启发式规则代价模型很粗糙。myisam/默认存储引擎没有事务、没有行锁表锁粒度的代表。做性能对比时你会经常回到这里看锁实现。innobase/InnoDB 引擎源码。4.1 里它还叫 innobase没并进 storage/ 目录代码风格和后来 5.1 之后差别很大但 B-tree 页分裂、插入缓冲的逻辑雏形都在。2.2 编译环境的三个硬指标gcc、glibc、make4.1 年代的主流编译器是 gcc 2.95 和 gcc 3.3但现代 Linux 发行版默认是 gcc 9这会导致一个经典问题新编译器对隐式声明的处理比老编译器严格得多4.1 源码里一些老式写法在 gcc 9 下直接报 error而不是 warning。先检查环境gcc --version make --version ldd --version | head -1常见做法是装一个 gcc 4.8 或 gcc 5 作为备用编译器配合 --with-gcc 参数指定路径。这里踩过一个大坑gcc 版本太高时编译 mysys/ 目录下的文件会报storage_size之类的类型不匹配错误很多人以为源码坏了其实只是编译器太新。# 安装低版本编译器以 Ubuntu/Debian 系为例 sudo apt-get install gcc-4.8 g-4.8 # 后续 configure 前导出 CC 和 CXX export CCgcc-4.8 export CXXg-4.8参数说明CC 和 CXX 是 autotools 体系识别的编译器变量导出后 configure 和 make 都会优先使用你指定的编译器。2.3 我验证过的最小依赖清单在干净的容器或虚拟机里需要的依赖比你想象得少。理论上只需要 gcc、make、autoconf、automake、libtool、ncurses-dev终端客户端依赖和一个能用的 shell。不需要 openssl-dev因为 4.1 的 SSL 支持是可选项而且老版本 OpenSSL 接口和现代版本完全不兼容干脆编译时把 SSL 关掉。# Debian/Ubuntu 环境 sudo apt-get install -y gcc-4.8 g-4.8 autoconf automake libtool ncurses-dev注意4.1 的官方文档说支持 Linux、Solaris、FreeBSD但我在 Solaris 上试过一次configure 通过了make 却在链接阶段因为系统库差异失败。后来只在 Linux 上跑通了——如果你是做跨平台验证建议先打死 Linux 这个基准别一开始就挑战 BSD。3. configure 与 make把 4.1 编译成可用的 InnoDB 实例3.1 configure 参数怎么选prefix、charset 与存储引擎configure 是编译老版本 MySQL 最关键的关卡。4.1 的默认配置把 MyISAM 作为默认引擎但我们需要 InnoDB 事务支持所以要显式启用。我验证过一组稳定可用的参数./configure \ --prefix/usr/local/mysql-4.1.11 \ --with-extra-charsetsall \ --with-charsetlatin1 \ --with-innodb \ --disable-dependency-tracking \ --with-mysqld-usermysql \ --without-query-cache \ --without-debug \ --without-ssl逐项说明--with-innodb必选。不加这个参数 InnoDB 引擎根本不会编译进去SHOW ENGINES 里看不到 InnoDB。很多人编译完发现没有事务引擎就是漏了这一步。--with-extra-charsetsall把附加字符集全部编进去后续才能用 ALTER TABLE CONVERT TO CHARACTER SET 做迁移。如果只编默认 latin1后面数据迁移时连 GBK 都不认。--without-query-cache4.1 的查询缓存是一个有争议的功能命中率低且全局锁开销大直接关掉省心。--without-ssl老版本 SSL 依赖 OpenSSL 0.9.x现代系统基本没有编译必炸不如关闭。--disable-dependency-tracking减少 make 阶段对头文件依赖的追踪能省不少编译时间。3.2 make 阶段的时间线从编译错误到可执行文件的常见卡点configure 通过后进入 make这一步的耗时在当时的机器上约 20~30 分钟现代虚拟机里 5 分钟内能跑完。但如果编译器版本不对你会在这里遇到第一个大坑make 21 | tee build.log常见的报错是mysys/mf_brkhme.cc: In function int strmov(...): error: register is deprecated现象是register关键字在新标准里被弃用gcc 4.8 还能当作警告容忍gcc 9 直接报 error。解决方式是加 CFLAGSexport CFLAGS-Wno-register -fpermissive export CXXFLAGS-Wno-register -fpermissive参数说明-fpermissive 让编译器把一些违反标准的写法降级为警告而不是硬错误-Wno-register 屏蔽 register 弃用警告。这两项是我回编译老 C 代码的保命组合。make 成功后检查关键产物ls -l sql/mysqld ls -l client/mysql如果这两个文件存在且权限正确编译阶段就结束了。使用 file 命令确认可执行格式file sql/mysqld输出 ELF 32-bit 或 64-bit 都正常但如果你在 64 位系统上编译出了 32 位二进制后续内存参数设置会受限建议 --enable-64bit 显式指定。3.3 验证二进制mysql_client_test 与手动 smoke test编译完成不代表能跑。我习惯先做一次快速的 smoke test不急着 install。手动初始化数据目录并启动mkdir -p /tmp/mysql-test ./sql/mysqld --no-defaults \ --datadir/tmp/mysql-test \ --socket/tmp/mysql-test.sock \ --skip-networking \ --user$(whoami) 逻辑说明--no-defaults 表示不读取任何配置文件--skip-networking 关闭 TCP 端口只监听 socket这样避免端口冲突也方便快速验证二进制是否能启动。如果这个命令能持续运行而不是闪退说明编译出来的核心没问题。再做一个最简单的 SQL 验证./client/mysql --socket/tmp/mysql-test.sock -e SELECT VERSION();能输出 4.1.11 就说明 mysqld 和客户端都活着。这一步过了再谈安装。4. 初始化与启动mysql_install_db 与 my.cnf 的 4.1 时代写法4.1 初始化到底做了什么权限表与数据目录make install 之后别直接启动 mysqld——老版本不像 5.7 之后那样可以在启动时自动初始化数据目录。4.1 需要手动执行 mysql_install_db 来创建系统库sudo make install cd /usr/local/mysql-4.1.11 sudo mkdir -p /var/lib/mysql-4.1 sudo chown -R mysql:mysql /var/lib/mysql-4.1 sudo ./bin/mysql_install_db \ --basedir/usr/local/mysql-4.1.11 \ --datadir/var/lib/mysql-4.1 \ --usermysql执行完后检查数据目录sudo ls -la /var/lib/mysql-4.1你会看到 mysql/ 子目录里面有 user、db、host 等表的 .frm 和 .MYD 文件。这些就是权限表mysql.user 表里初始有两个 root 账号一个允许本机 socket 登录一个允许 localhost TCP 登录密码默认是空的。4.2 my.cnf 的最小可用配置与 key_buffer 参数4.1 时代 my.cnf 的写法跟现在很不一样没有 [mysqld] 下的 innodb_buffer_pool_size那个参数要 5.0 之后才有InnoDB 缓冲区参数叫 innodb_buffer_pool_size 的前身——在 4.1 里它叫 innodb_buffer_pool_size 但实际单位是字节而且默认只有 8MB。写一个最小配置[mysqld] basedir /usr/local/mysql-4.1.11 datadir /var/lib/mysql-4.1 port 3306 socket /var/lib/mysql-4.1/mysql.sock user mysql skip-bdb skip-federated key_buffer 64M table_cache 256 max_connections 100 innodb_data_file_path ibdata1:32M:autoextend innodb_buffer_pool_size 128M参数说明key_buffer决定 MyISAM 索引缓存大小4.1 里这是最重要的内存参数。设置为物理内存的四分之一左右即可。innodb_buffer_pool_sizeInnoDB 数据页缓存4.1 里默认只有 8MB做任何实际测试前至少调到 128MB。innodb_data_file_path必须用 autoextend否则 InnoDB 表空间写满 32MB 后就报错新手经常在这翻车。4.3 连接不上时的排查顺序socket、端口、进程日志老版本没有 performance_schema也没有 information_schema排错完全靠日志和经验。我排查时按这个顺序来ps aux | grep mysqld第一步确认进程存在。第二步看日志sudo tail -50 /var/lib/mysql-4.1/*.err4.1 的错误日志默认写在数据目录下文件名是主机名.err。如果进程起来了但客户端连不上先看 socket 路径是否一致sudo ./bin/mysql --socket/var/lib/mysql-4.1/mysql.sock -uroot如果报Cant connect to local MySQL server through socket通常是 socket 路径不一致或进程根本没起来。如果报 Access denied说明 root 密码已有变化用 --skip-grant-tables 启动再重置。sudo ./bin/mysqld_safe --skip-grant-tables --skip-networking sudo ./bin/mysql -uroot跳过权限表登录后执行UPDATE mysql.user SET PasswordPASSWORD(newpass) WHERE Userroot; FLUSH PRIVILEGES;这一点很重要4.1 的 user 表里 Password 字段是 4.1 风格的 41 字节哈希和 5.7 之后完全不同重置密码时用 PASSWORD() 函数而不是手动填哈希。5. 老版本避坑编译、字符集、InnoDB 的五个典型翻车现场5.1 configure 报错却无日志config.log 的最后 50 行才是真相现象执行 configure 到某个检测环节直接中断终端只显示一句话没有具体原因。原因autotools 把检测失败信息写进 config.log终端默认不输出。解决不要反复重跑 configure先看 config.log 尾部tail -100 config.log | grep -A20 error我遇到过一次是链接测试程序失败原因是缺 libcurses。装上 ncurses-dev 之后 configure 顺利通过。从那以后我养成了习惯任何 autotools 项目 configure 失败先看 config.log 再下结论。5.2 make 死在 yacc/lex 阶段bison 版本太新现象make 到 sql/ 目录时停在sql_yacc.cc报错提示语法冲突或 undefined rule。原因4.1 的语法分析器需要老版本 bison 生成的解析表bison 2.x 生成的文件和现代 bison 3.x 不兼容。解决安装老版本 bisonsudo apt-get install -y bison2.7*如果系统源里没有就下载 bison 2.7 源码手动编译。装完清掉之前生成的 yacc 相关文件再重新 makemake clean make5.3 字符集乱码4.1 的 utf8 不是现在的 utf8现象从 4.1 导出数据用现代 MySQL 导入后中文变成问号或者反过来。原因4.1 的 utf8 只支持基本多语言平面每个字符最多 3 字节不包含 emoji 和冷僻汉字而且 4.1 的 utf8 排序规则和 5.7、8.0 也不完全一致。解决导出时显式指定字符集导入时也显式指定mysqldump -uroot -p --default-character-setutf8 --compatibleno_keywords olddb dump.sql导入前在目标库先设置会话字符集mysql --default-character-setutf8 targetdb dump.sql5.4 InnoDB 启动崩溃表空间文件损坏与 autoextend现象mysqld 启动时报 InnoDB 错误提示ibdata1尺寸不匹配或 log 文件大小不一致。原因4.1 的 InnoDB 在非正常关机时 recovery 能力弱尤其是日志文件和表空间文件不一致时直接拒绝启动。解决把 innodb_force_recovery 从 1 开始逐级试[mysqld] innodb_force_recovery 1每次启动后立刻用 mysqldump 导出数据然后重建数据目录。4.1 的 force_recovery 到 6 级时只读不写能救多少算多少。5.5 root 密码失效禁用了 root 的远程权限现象本地 socket 能登录但通过 TCP 用 root 连接时报 Access denied。原因4.1 默认只在 user 表里放了两条 root 记录host 是 localhost 和 127.0.0.1。没有 host 为 % 的记录。解决插入一条允许本机网络登录的记录但别开外网 rootCREATE USER root127.0.0.1 IDENTIFIED BY newpass; GRANT ALL PRIVILEGES ON *.* TO root127.0.0.1 WITH GRANT OPTION; FLUSH PRIVILEGES;6. 数据迁移实战把 4.1 的数据安全搬到现代 MySQL6.1 mysqldump 的版本兼容边界与 --compatible 参数4.1 导出的数据直接灌进 8.0 大概率失败原因集中在三处语法结构差异、字符集定义方式、以及索引长度限制。一个可靠流程是先用老版本 mysqldump 导出再做文本级修正。/usr/local/mysql-4.1.11/bin/mysqldump \ -uroot -p \ --default-character-setutf8 \ --opt \ --quote-names \ --skip-lock-tables \ olddb olddb_dump.sql参数说明--opt 是 --quick --add-drop-table --add-locks --extended-insert 的合体导出速度更快--quote-names 让表名和字段名带上反引号避免新版本把老库的关键字当语法错误。导出后检查文件里有没有 TYPEMyISAM 或 TYPEInnoDB 这种老写法新版本只认识 ENGINEsed -i s/TYPEInnoDB/ENGINEInnoDB/g olddb_dump.sql sed -i s/TYPEMyISAM/ENGINEMyISAM/g olddb_dump.sql6.2 字符集迁移的后悔药从 latin1 到 utf8mb4 的完整步骤这是很多老库换新库最痛的点。4.1 默认 latin1但很多业务里实际存的是 UTF-8 字节流——因为当年客户端连接时手动 SET NAMES utf8数据本身是 UTF-8只是列定义是 latin1。直接转 CONVERT TO CHARACTER SET 会双重转换把数据改坏。正确的做法是先确认列里实际字节编码SELECT HEX(LEFT(title, 10)) FROM news LIMIT 5;如果十六进制里能看到 E4 B8 AD 这种 UTF-8 三字节序列说明数据本身是 UTF-8不要做列转换只要改列定义mysql -uroot -p --default-character-setutf8 olddbALTER TABLE news MODIFY title TEXT CHARACTER SET utf8mb4;注意这里没写 CONVERT TO只用 MODIFY 改列属性数据字节没有被动过。之后再修改客户端连接规则mysql -uroot -p --default-character-setutf8mb4 olddb如果数据里混着真正的 latin1 编码比如 À、é 这种单字节才需要先转成二进制再转ALTER TABLE news ADD COLUMN title_backup TEXT; UPDATE news SET title_backup CONVERT(CAST(title AS BINARY) USING utf8mb4);操作前务必全库备份多留一条后悔药。做完迁移后用两个指标验证COUNT(*) 行数一致以及关键字段的 MAX(LENGTH(field)) 和 MAX(CHAR_LENGTH(field)) 比例接近 3:1说明中文字符没有丢失。从那以后我每次做老版本 MySQL 迁移都强制走一遍「先看真实编码、再改列属性、最后改连接方式」的顺序不在任何一步用默认选项。希望帮到你。本文还有配套的精品资源点击获取