简介：MySQL 8.4.6 LTS 社区版 Windows 离线安装包（ZIP 格式），面向需要在生产或学习环境中部署稳定数据库的开发者、DBA 及运维人员。该版本为长期支持版，相比短期版本可获得更持续的安全更新与维护，适合对系统稳定性要求较高的应用场景。资源共 2000 个文件，包含大量 C/C++ 源码头文件、Java 程序、Python 脚本、Shell 脚本及配置文件，涵盖 MySQL 底层存储引擎、查询优化、网络协议与压缩算法等核心模块，便于学习者深入阅读源码或进行二次开发。压缩包约 521MB，内容预览中的 zstd、openssl、http、ftp 等文件提示资源覆盖了数据处理、安全通信及网络服务相关实现。已有 427 人浏览学习。ZIP 包可直接解压使用，省去安装向导的繁琐配置，同时保留了完整的目录结构，适合快速搭建本地数据库环境，也适合通过阅读源码理解 MySQL 内部运行机制。

1. MySQL 8.4.6 先回答“下哪个版本”：LTS 才是能上生产的那个

打开 MySQL 官网 Downloads 页，版本一排排摆在那里，新手很容易直接点最大的那个数字下载。8.4 这个版本号乍一看比 8.0 大，比 9.x 小，位置尴尬，但它恰恰是 MySQL 在 8.0 长期维护结束后的第一个 LTS（Long Term Support）版本。简单说，8.4 是给生产环境用的“稳妥款”，9.x 是给尝鲜党用的“创新款”。这份资源给的 mysql-8.4.6.zip 是 Windows 下的 zip 免安装包，不经过 MSI 引导，目录结构完全自己掌控。适合两种人：一种是不想让安装器往系统里塞一堆隐藏改动、想明确知道每个文件落在哪的运维；另一种是本地开发需要快速起一个干净实例、随时能删能重建的开发者。这篇文章会把从解压到初始化、注册服务、改密码策略到最后拿 binlog 做恢复验证的完整链路走一遍。

2. 为什么选 8.4 LTS，以及 zip 包的目录结构到底在说什么

2.1 LTS 与 Innovation 怎么选：别拿生产环境赌新特性

MySQL 的版本发布节奏从 8.0 之后变得很有规律：一个 LTS 版本后面跟着若干个 Innovation 版本。8.4 是首个 LTS，意味着它会有较长的错误修复和安全更新窗口；9.x 这类 Innovation 版本的特性更新更快，但维护周期只覆盖到下一个版本发布。对绝大多数业务系统来说，数据库是底座不是玩具，选型的核心逻辑是“这个版本我能安全用多久”，而不是“这个版本多了哪些新函数”。

我在本地跑测试环境经常用 9.x 看新特性，但凡是沾到生产、沾到数据迁移、沾到要部署到客户现场的，一律锁定 8.4。还有一点容易被忽略：8.0 已经进入生命周期末尾，新项目如果现在才从 8.0 起步，等于刚上车就面临换乘。8.4 的 SQL 语法、系统表结构、默认配置跟 8.0 基本平滑，迁移成本低，同时避开了 8.0 后期才暴露出来的一些老问题。这份资源锁定的 8.4.6 属于 LTS 中的补丁版本，修复了此前若干已知 bug，直接下这个版本号，省得自己再去对照 release notes 挑版本。

2.2 zip 包的目录结构：bin、data、my.ini 各归其位

拿到 zip 包之后，第一件事不是双击任何 exe，而是先解压到一个路径纯英文、没有空格的位置。我一般放在D:\mysql-8.4.6-winx64。解压后里面的核心目录长这样：

这里有个关键认知：zip 包不像 MSI 安装版会自动创建 data 目录、自动注册 Windows 服务、自动写注册表。它把决定权完全交给你。好处是目录结构透明，坏处是新手容易漏掉某一步导致服务起不来。MySQL 8.4 初始化完成后，data 目录里会出现mysql、performance_schema、sys等系统库的文件夹，以及一组binlog.000001之类的文件——这些就是实例真正的“身体”。

提示：如果解压路径带中文或空格，后面注册服务、执行初始化时大概率会碰到诡异的路径解析问题。先花半分钟把目录放对位置，能省掉后面一整晚的排查时间。

3. 从 zip 到能跑的实例：my.ini、初始化、服务注册三步走

3.1 先把 my.ini 写好：字符集、端口、数据目录一次到位

很多教程上来就让你执行初始化命令，结果跑完发现字符集不对、端口被占、日志乱码。正确顺序是先写好配置文件，再初始化。在解压目录下新建my.ini，这是 8.4 在 Windows 下读取配置的默认文件名。下面这份配置是我在 Windows 上部署 8.4 的常用底子：

[mysqld] basedir=D:/mysql-8.4.6-winx64 datadir=D:/mysql-8.4.6-winx64/data port=3306 character-set-server=utf8mb4 collation-server=utf8mb4_0900_ai_ci default-time-zone=+08:00 max_connections=200 max_allowed_packet=64M # 8.4 默认 binlog 未开启，需要恢复场景时手动打开 log_bin=ON binlog_format=ROW server_id=1 [client] default-character-set=utf8mb4

basedir和datadir用的是正斜杠，避免反斜杠在配置解析时被当成转义字符。port=3306是默认端口，如果本机已经有其他 MySQL 实例在跑，改成 3307 或 3308。max_allowed_packet=64M是 8.4 的默认值，相比 8.0 的 4M 大得多，处理大字段和批量导入时不容易翻车。binlog_format=ROW是后面做恢复验证的前提，8.4 默认不开启 binlog，生产环境建议显式打开。

3.2 初始化数据目录：mysqld --initialize-insecure 到底做了什么

配置文件就位后，用管理员权限打开 cmd，切到 bin 目录执行初始化。这里我给两种初始化方式：

cd /d D:\mysql-8.4.6-winx64\bin :: 方式一：生成空密码 root 账号（本地开发推荐） mysqld --defaults-file=D:/mysql-8.4.6-winx64/my.ini --initialize-insecure --console :: 方式二：生成随机临时密码（生产环境推荐） mysqld --defaults-file=D:/mysql-8.4.6-winx64/my.ini --initialize --console

--initialize-insecure会创建一个密码为空的 root 账号，方便本地环境秒进；--initialize则生成一个随机临时密码，打印在控制台输出里，首次登录后必须改密。生产或客户现场我基本只用--initialize配合--console，把输出的临时密码存好。--console让错误信息直接打印到窗口而不是写进错误日志，排查时能立刻看到初始化报错。初始化成功后窗口会停住然后退出，data 目录出现大量文件。

3.3 注册 Windows 服务并验证连接

初始化完成后，MySQL 还只是“能前台跑”，没注册成服务。前台启动可以这样验证：

mysqld --defaults-file=D:/mysql-8.4.6-winx64/my.ini --console

看到ready for connections字样说明实例起来了。确认没问题后，Ctrl+C 停掉，然后注册为 Windows 服务：

mysqld --install MySQL84 --defaults-file=D:/mysql-8.4.6-winx64/my.ini net start MySQL84 mysql -uroot -p SELECT VERSION();

--install后面的MySQL84是服务名，自己起一个有意义的名字，后面sc delete MySQL84或mysqld --remove卸载时就不用猜服务名。服务启动后执行mysql -uroot -p，配合 3.2 的初始化方式输入对应密码。看到8.4.6版本号输出，这一步就算彻底通了。

4. 8.4 的默认值变化：root 密码、认证插件、SSL 与连接池的连锁反应

4.1 8.4 默认认证插件变了，老客户端直接翻车

8.4 里默认的账号认证插件是caching_sha2_password，mysql_native_password在 8.4 中进入废弃流程。这个变化的直接后果是：用 5.x 时代的旧驱动或者老版本 Navicat 连接时，报错形如Authentication plugin 'caching_sha2_password' cannot be loaded或者握手直接失败。常见做法是升级客户端驱动到支持 caching_sha2_password 的版本；如果客户端版本老旧且无法升级，可以单独为旧客户端建一个老插件账号：

CREATE USER 'legacy_app'@'%' IDENTIFIED WITH mysql_native_password BY 'YourStrongPass'; GRANT ALL PRIVILEGES ON yourdb.* TO 'legacy_app'@'%'; FLUSH PRIVILEGES;

这是“兼容”不是“推荐”，新项目一律用默认认证方式。另外注意 8.4 对密码强度有默认校验，太短的密码会被VALIDATE_PASSWORD组件拦下来，本地测试环境想用弱密码，需要在初始化之后手动卸载或调整 validate_password 的强度参数。

4.2 8.4 的安全默认项：SSL、密码过期策略和“默认不是 0”

8.4 在安全默认值上收紧了一轮。服务端默认开启 SSL，客户端连的时候如果显式写了useSSL=false，部分驱动版本会直接抛 SSL 连接错误。JDBC 连接串常见的写法是：

jdbc:mysql://localhost:3306/yourdb?useSSL=true&sslMode=REQUIRED&serverTimezone=Asia/Shanghai

sslMode=REQUIRED明确要求加密连接，useSSL=true是老驱动兼容参数，两者同时写是为了适配不同驱动版本。还有一点容易被忽略：8.4 的password_expire策略和default_authentication_plugin都跟 8.0 初期不完全一样。如果你发现某天服务突然要求改密，别慌，先查SHOW VARIABLES LIKE 'default_password_lifetime'。热搜里常有人问“mysql 设置默认值为 0”，其实很多时候指的就是这类默认策略——想要密码不过期，就显式设置为default_password_lifetime=0，想要其他参数恢复为 0，先看这个变量名是什么，别拿sql_mode里的NO_ZERO_DATE直接杠。

4.3 连接池参数怎么配：HikariCP 与 8.4 驱动的配合

应用侧连接池是另一个高频翻车点。8.4 的驱动类要用com.mysql.cj.jdbc.Driver，老驱动类com.mysql.jdbc.Driver在 8.0 后已被移除。Spring Boot 整合 HikariCP 时的核心配置：

spring: datasource: url: jdbc:mysql://localhost:3306/yourdb?useSSL=true&sslMode=REQUIRED&serverTimezone=Asia/Shanghai username: root password: yourpassword driver-class-name: com.mysql.cj.jdbc.Driver hikari: maximum-pool-size: 20 minimum-idle: 5 connection-timeout: 30000 max-lifetime: 1800000

maximum-pool-size=20对应 3.1 里max_connections=200的余量，别把连接池最大值设到超过数据库max_connections。max-lifetime设为 30 分钟，短于数据库侧的wait_timeout默认 8 小时，避免连接被服务端回收后应用还在用连接池里的死连接。这类参数看着琐碎，但线上“连接池连接耗尽”事故十有八九是这里没对齐。

5. 避坑排查：8.4 安装与运行最常翻车的五个地方

5.1 服务启动又停止，报 1067 错误

现象：net start MySQL84提示服务启动后自动停止，事件查看器里报 1067 或直接看 MySQL 错误日志有unknown variable。

原因：最常见的是 my.ini 里写了 8.4 不认识或已删除的参数，比如query_cache_size，这个功能在 8.0 就移除了，写在配置里直接导致启动失败；其次是basedir或datadir路径写错。

解决：用前台模式跑一次mysqld --defaults-file=D:/mysql-8.4.6-winx64/my.ini --console，错误会直接打在屏幕上。看到unknown variable就逐行核对配置项，删掉 8.4 不支持的参数再试。前台起得来，服务基本就没问题。

5.2 initialize 报错或重复初始化导致 data 目录不干净

现象：执行mysqld --initialize-insecure时提示data directory already exists或Cannot find error message file。

原因：data 目录不是全新空目录。初始化脚本要求目标目录为空，之前失败留下的半成品文件会导致二次初始化失败；Cannot find error message file则是share目录缺失或解压不完整。

解决：把 data 目录里的内容全部清空再初始化，或者干脆换一个新的目录路径改到 my.ini 里。初始化成功后不要再重复执行 initialize，之后要重置数据就直接把 data 目录备份后清空，删掉服务重新来过。

5.3 连不上：2003 Can't connect，问题不一定在 MySQL

现象：mysql -uroot -p报ERROR 2003 (HY000): Can't connect to MySQL server on 'localhost:3306'，但服务明明在跑。

原因：端口被占用或服务实际没起来。netstat -ano | findstr 3306看一下监听状态，另一个 MySQL 实例占了 3306 是高频原因。

解决：

netstat -ano | findstr 3306 tasklist | findstr 上文查到的PID

看到端口被其他进程占着，要么改 my.ini 的端口，要么停掉冲突进程。服务没起来的情况，先回 5.1 前台模式确认实例能起，再查服务注册名是否对得上。

5.4 跑大查询时 Got error 28 from storage engine

现象：批量导入或复杂查询中途报The table 'xxx' is full或Got error 28，部分表直接标记为损坏。

原因：磁盘写满或 tmp 目录空间不足。MySQL 的排序、临时表都会写临时文件，默认写到系统临时目录，C 盘一旦撑不住就疯狂报错。

解决：清理磁盘是第一优先级；同时可以在 my.ini 里设置独立的tmpdir=D:/mysql-tmp，指向空间充裕的盘。8.4 的max_allowed_packet默认已经 64M，如果还报package too large，检查是不是单条 SQL 超过了这个限制。

5.5 远程连不上，3306 被防火墙挡

现象：本机连 MySQL 正常，其他机器 telnet IP 3306 不通，应用连库超时。

原因：Windows 防火墙默认拦外部入站 3306。解决要用管理员权限放行端口：

netsh advfirewall firewall add rule name="MySQL 3306" dir=in action=allow protocol=TCP localport=3306

这里顺带提醒：bind-address默认是*，8.4 默认监听所有网卡，但如果你为了安全只想本机访问，改成bind-address=127.0.0.1更稳妥。远程账号的 host 也要对应改成'user'@'%'或指定 IP 段，否则即使防火墙放行，账号本身也连不进来。

6. 给 8.4 配一个“后悔药”：用 binlog 做一次回放验证

最后分享一个我每次装完 8.4 都会强制走一遍的流程：手动制造一次误删数据，再用 binlog 把数据捞回来。这个验证做完，你对 binlog 的信心和对“数据丢了先别慌”的判断力就完全不一样了。

先确认参数，3.1 里如果写入了log_bin=ON和server_id=1，这时候已经生效：

SHOW VARIABLES LIKE 'log_bin';

然后模拟误删：建一张测试表，插入几行，执行DELETE FROM test_tbl WHERE id <= 3;。接着在 bin 目录执行：

mysqlbinlog --no-defaults --start-datetime="2025-01-10 09:00:00" --stop-datetime="2025-01-10 09:30:00" D:/mysql-8.4.6-winx64/data/binlog.000001 | mysql -uroot -p

--start-datetime和--stop-datetime圈定误删时间窗口前后，binlog 文件按时间递增，实际生产环境要结合SHOW BINARY LOGS;确认文件序号。重放之后去查test_tbl，你会发现数据回来了——但前提是：binlog 格式是ROW，且误删之后没有额外写入大量无关操作覆盖了窗口期。最稳妥的恢复习惯不是事后解析，而是“备份 + binlog 增量重放”：全量备份恢复到一个临时实例，再用 binlog 把备份时间点到误删时间点的增量同步过去。

从那以后，我每次部署 MySQL 8.4 都强制走一遍这个流程：先确认log_bin=ON，再手动制造一次误删，最后用 mysqlbinlog 回放验证。十分钟的验证，换的是“真出事时不用赌运气”的确定感。希望你也能在部署完的第一天就把这个习惯建立起来——真到数据没了那一刻才翻文档，没人愿意体验那种心跳加速的感觉。希望帮到你。

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