简介《MySQL 4.0.pdf》是一份聚焦MySQL 4.0版本的开源关系型数据库参考资料适合数据库管理员、后端开发人员及系统学习数据库原理的读者用于理解经典版本的功能体系与运维思路。资源为单个PDF文件压缩包仅334KB内容精炼便于离线查阅。已有95人学习浏览。文档围绕数据库核心场景展开涵盖SQL增删改查、表与索引设计、事务处理与一致性保障、备份恢复策略、用户权限与访问控制、InnoDB与MyISAM引擎调优以及存储过程、触发器、主从复制和日志监控等进阶主题同时提及PHP、Python、Java等API连接方式有助于从安装配置到性能优化形成完整认知。虽然MySQL 4.0已是较老版本但关系型数据库的基本原理和运维经验对理解后续版本仍有参考价值。1. MySQL 4.0.pdf20年前的数据库手册为什么今天还有人按它干活MySQL 4.0.pdf这个名字通常会出现在三类人的电脑里接手老系统的运维、做等保整改的工程师、以及翻课件找历史资料的老师。它对应的是一份关于MySQL 4.0版本的技术文档而4.0是2003年前后发布的数据库版本一个今天绝大多数开发者只在面试题里听过、但依然跑在一批工控、医疗、政务和早期互联网业务系统中的版本。这份PDF之所以还有价值不是因为它讲了多少高深原理而是因为老系统还在生产环境里跑出了问题必须按老手册重新搭环境、查参数、做迁移。这篇文章就按4.0能干什么、怎么搭、坑在哪、怎么迁的顺序把这份文档变成你今天能落地的步骤。2. MySQL 4.0 到底是什么版本边界与能力地图2.1 版本坐标4.0 在 MySQL 演进中的准确位置拿到这份PDF先别急着翻安装章节花五分钟搞清楚4.0在整个MySQL家族里的坐标后面所有操作都会顺很多。MySQL的版本演进大致是这么一条线3.23是2000年前后大量Web系统在用的版本4.0是2003年的过渡版本4.1在2004年重构了字符集体系并引入子查询5.0在2005年带来存储过程、视图和触发器5.5在2010年把InnoDB扶正为默认引擎而8.0则是2018年之后的主流长期支持版本。4.0的位置非常特殊它比3.x多了不少现代数据库的雏形但距离我们熟悉的5.7/8.0还差着一整个时代。用一张表可以看得很清楚版本发布时间关键能力变化3.232000年MyISAM成为默认引擎大量老网站基于此版本4.02003年引入UNION、查询缓存、InnoDB改进、SSL连接4.12004年引入UTF-8字符集、子查询、预处理语句5.02005年引入存储过程、视图、触发器5.52010年InnoDB成为默认存储引擎8.02018年窗口函数、CTE、移除查询缓存这张表的重点是提醒你一件事如果业务系统需要子查询、需要UTF-8、需要触发器4.0在功能上是不达标的。它不是老一点点的5.7而是能力边界完全不同的一个版本。很多从4.0迁移上来的系统代码里全是拆多条SQL、应用层做联表、以及用GBK编码存中文的痕迹这些都是被版本逼出来的。2.2 存储引擎与锁MyISAM 默认InnoDB 还是选装件这份PDF如果翻到存储引擎章节一定会花不少篇幅讲MyISAM和InnoDB。原因很简单4.0时代默认引擎是MyISAM建表时不指定engine出来的表就全是MyISAM。今天的工程师见惯了InnoDB对默认表锁没有概念但4.0不是这样。MyISAM和InnoDB在4.0里的差别我用一个表格给读者讲清楚对比项MyISAMInnoDB4.0事务不支持ACID支持ACID可提交回滚锁粒度表级锁行级锁外键约束不支持支持全文索引支持不支持崩溃恢复无redo log靠repairredo log自动恢复典型场景读多写少、报表、日志业务交易、并发写三条值得记住的结论。第一4.0里选引擎是建表时通过engine参数显式声明的行为你不写就默认MyISAM这个习惯沿用至今但4.0时代忘写的代价远高于今天。第二MyISAM的表级锁在并发写场景下会放大问题锁竞争导致的卡死是当年最大的运维痛点之一。第三InnoDB在4.0里是有的但从官方二进制包到my.cnf的默认配置往往把InnoDB数据文件和缓冲池调得极小甚至关闭。想用事务必须手动打开相关参数这一点和后来开箱即InnoDB的体验完全不同。2.3 SQL能力边界没有子查询、没有视图、没有 UTF-8 的日子把4.0理解成低配版MySQL是很多人的直觉但它缺的不是性能而是几项今天看起来和吃饭一样的基础功能。子查询在4.1才引入4.0里写where id in (select ...)直接语法错误只能拆成多条SQL或依赖JOIN。视图和存储过程在5.0才引入4.0时代复杂报表只能靠应用层拼SQL业务逻辑全在代码里。预处理语句同样是4.1引入的这意味着4.0时代的SQL拼接几乎全靠字符串拼接加上老代码常见的root弱口令SQL注入风险比今天高一个数量级。字符集是另一个大坑。4.0的字符集体系很简陋默认latin1。中文环境要在my.cnf里设default-character-setgbk或者在连接时执行set names gbkutf8在当时还不是正式支持的字符集。4.1重构后字符集支持从服务器级推进到服务器/库/表/连接四级这才是今天utf8mb4的基础。此外4.0的排序规则也简单ORDER BY只能按单字符集排序跨字符集比较经常出问题这也是mysql排序在老系统上让人头疼的原因之一。这一段的价值在于当你拿到老系统的建表语句和查询代码时能一眼看出哪些是当年为绕过4.0限制而写的妥协代码。比如查两次先取id再取详情多半是子查询缺失的痕迹字段全是varchar日期用字符串存是当时的常见做法。看懂这些你才不会按5.7的思维去嘲笑老代码也才能在迁移时准确评估改造量。3. 按文档搭一个 MySQL 4.0 环境安装步骤与参数清单3.1 安装从二进制包到 mysqld 起来因为标题指向的是文档和手册类资源这一章我用步骤和参数描述来还原安装过程不堆大段代码。基于MySQL 4.0时代最常见的企业部署方式也就是Linux下用官方二进制tar包安装步骤大致分五步。第一步创建系统用户。用mysql用户运行mysqld而不是root这在4.0时代就是标准安全实践。第二步解压二进制包到/usr/local/mysql做一个软链接或直接把路径写进PATH。第三步初始化系统库4.0没有像5.7那样的--initialize机制用的是scripts/mysql_install_db脚本这个脚本会创建mysql库和权限表。第四步编写my.cnf把socket、datadir、pid文件、字符集、连接数等参数写进去4.0的配置风格是全局一个my.cnf不区分初始化和运行参数。第五步启动服务使用mysqld_safe脚本拉起mysqld然后用mysqladmin ping确认存活。这里有一个4.0特有的坑mysql_install_db这一步如果没跑mysqld能启动但mysql -uroot登录会报错错误信息还不太直观。很多初次接触老版本的人卡在这一步半天最后发现只是没初始化系统表。另外4.0的mysqld_safe会默认把错误日志写到数据目录下的hostname.err排查启动问题先看这个文件。3.2 参数清单字符集、连接数、缓冲区、InnoDB开关把这份PDF翻到服务器配置章节真正要在生产环境里盯的参数其实就那几个。我把它们整理成一个参数表并附上4.0环境下的建议值方便直接抄作业。参数含义4.0时代建议说明default-character-set默认字符集gbk 或 latin1中文环境务必设否则应用层看数据全是乱码max_connections最大连接数200-500默认100对老ERP和网站并发不够key_buffer_sizeMyISAM索引缓冲物理内存的25%左右4.0的MyISAM全靠它调大提速明显query_cache_size查询缓存读多写少才开写频繁场景设0关闭innodb_buffer_pool_sizeInnoDB缓存物理内存的50%左右用InnoDB才需要4.0默认值极小innodb_data_file_pathInnoDB表空间ibdata1:10M:autoextend不设的话InnoDB可能直接不启动innodb_file_per_table独立表空间ON4.0默认共享表空间显式开启才是独立表文件这个表是给照着文档搭环境的人用的。很多PDF里的参数到今天已经改了名或语义变了比如key_buffer_size在5.7还在到8.0里因为InnoDB成为默认引擎强调点完全不一样。如果你搭的是4.0环境务必按这个表设而不是从网上抄一份5.7的my.cnf来用。3.3 最小验证建库、建表、跑通查询环境起来后用下面这组操作验证可用性。不涉及大段脚本我按步骤拆开说。第一步登录验证。执行mysql -uroot -p能进就说明mysqld和socket正常。第二步建库。执行create database legacy_db default character set gbk注意4.0里字符集只能写gbk或latin1写utf8会直接报错。第三步建表并验证引擎。执行create table t1 (id int primary key, name varchar(50)) engineinnodb然后通过show table status like t1查看Engine字段。要验证事务就执行begin、insert、rollback再查表没有数据即说明事务生效。第四步验证查询缓存。执行一个select后通过show status like Qcache_hits观察命中数是否增加这是4.0引入的新特性也是这个版本和3.x最直观的区别。这四步跑完你的环境就具备继续做兼容性测试的基础了。如果是老系统迁移项目我一般会在这个环境上直接导入生产库的mysqldump备份做一轮应用级冒烟测试而不是一上来就动生产。4. MySQL 4.0 避坑清单字符集、锁与连接的 5 个真实坑4.1 坑一中文全部乱码数据看着像锟斤拷现象从4.0导出的数据在5.7里显示为乱码或者在4.0里插入的中文客户端select出来全是锟斤拷一类的替换字符。原因4.0的字符集默认latin1中文是按字节硬塞进去的。当年的业务系统在连接串里没有指定编码客户端和服务器之间也缺乏字符集协商机制数据落库后没有正确的字符集标记。导出再导入时编码链条断裂字符就变成了乱码。解决先执行show variables like character_set%确认当前库和连接的实际字符集。如果库是gbk连接也必须用gbk导入时在mysqldump命令里加--default-character-setgbk参数。如果数据已经是乱码且无法回源唯一的办法是找到应用层最初写入时的编码通过翻代码或看历史维护记录确定原始编码再写脚本按字节流转码。这种修复成本很高所以我的习惯是动手改数据前一定先对原库做整库备份。4.2 坑二MyISAM 表崩了mysqld 启动后立刻退出现象服务器异常断电或进程被kill -9后mysqld起不来错误日志里出现Table ./库名/表名 is marked as crashed and should be repaired。原因MyISAM没有redo log崩溃安全靠的是写完就落盘这一层。断电或强杀进程把数据文件和索引文件写坏了mysqld启动扫描时发现表损坏直接拒绝服务。解决不要急着删表先用myisamchk修复。常见做法是停掉mysqld然后执行/usr/local/mysql/bin/myisamchk -r /var/lib/mysql/库名/表名修复完成后再执行myisamchk -q重建索引。修复前要把原数据文件备份一份修复后可以再用mysqlcheck复查一遍。重点是必须先停mysqld再跑myisamchk否则一边写一边修会造成二次损坏这是我踩过的血泪教训。4.3 坑三mysql 客户端连接报错认证方式与 5.7 完全不同现象用mysql -uroot -p连接密码正确却报Access denied或者旧系统程序里报无法连接。原因MySQL 4.0用的是老版password()哈希算法生成40位十六进制密文和4.1以后、5.7/8.0的认证插件不兼容。如果你手里的密码是在4.0里设的拿5.7的客户端或新版驱动去连握手阶段就过不去报的错很迷惑。解决测试连接时用低版本客户端或者在应用驱动里指定兼容老认证的方式。如果是从5.7读4.0的备份不要赌密码一样就行备份文件里的权限表密码字段格式完全不一样导入后需要重新设置密码。这类认证不兼容问题是4.0向任意新版本迁移时最先暴露的坑建议迁移前先单独验证认证协议兼容性。4.4 坑四MyISAM 表锁把业务锁死现象业务高峰期某张表的UPDATE或INSERT一直夯住show processlist里全是Waiting for table lock。原因MyISAM是表级锁一个写操作会把整张表锁住后续读写全部排队。4.0时代很多报表系统用MyISAM存流水一到月底跑批就雪崩。这本质上是MySQL锁的分类问题——MyISAM表锁和InnoDB行锁是两个设计思路选错引擎在并发场景下代价很大。解决如果是读写混合业务把核心表改成InnoDB执行alter table 表名 engineinnodb即可。如果必须保留MyISAM考虑按时间或业务维度拆表把热表变小减少锁竞争时间。还有一个临时方案在应用层做读写分离但4.0时代复制机制比较原始主从延迟明显不建议过度依赖。4.5 坑五查询缓存导致的灵异慢查询现象同一个select第一次很快第二次很快第三次突然变慢或者更新刚提交下一次查询反而更慢。原因4.0引入的query_cache在表有更新后会把该表所有缓存条目全部失效下一次查询需要重新解析、重新执行。写多读少场景下缓存失效的成本比直接查询还高。解决执行show variables like query_cache_type检查当前状态。如果业务写多把query_cache_type设为OFF、query_cache_size设为0彻底关闭查询缓存。这是MySQL 8.0最终移除查询缓存的前瞻性原因在真实负载下它的收益非常有限。老系统上这个参数的默认值往往是开启的关掉之后写性能会有可见改善。5. 从 4.0 迁到 5.7/8.0动手前先做这三件事迁移老库最怕的不是数据量而是老版本特有的语法和数据结构在新环境里变成一堆报错。我建议动手前先做三件事。第一做一次全量导出并检查语法兼容性。在4.0上执行mysqldump -uroot -p --default-character-setgbk --all-databases legacy.sql然后把导出的sql文件拿到5.7或8.0的测试实例里执行source导入重点观察两类报错一类是CREATE TABLE语句里的TYPEMyISAM老语法需要用文本替换把TYPE改成ENGINE另一类是字符集声明不匹配导入前把文件头的SET NAMES latin1改成SET NAMES gbk。这一步能暴露90%的迁移障碍。第二核对权限表和账号认证方式。4.0的user表结构和5.7完全不同MySQL系统库是独立的不能直接覆盖导入。迁移时只导业务库然后在新环境里重新创建账号和授权。连接旧系统的程序如果用了老密码哈希要在新环境里改用mysql_native_password或更新驱动。第三先跑通核心事务再切流量。选一张有代表性的业务表在4.0和生产环境同时执行同样的insert、update、rollback对比结果一致性。确认事务行为一致后再做全量数据校验比如对比行数和关键字段的checksum。我见过太多迁移项目死在数据好像一样但业务不对上根源就是字符集在中间环节又变了一次。这些年我从4.0迁过好几套系统养成了一个习惯迁移方案里永远预留一个回退日导入失败就整体回退不做原地修复。这个习惯救过我不止一次。希望帮到你。本文还有配套的精品资源点击获取