MySQL 8.4.6 LTS Windows zip包安装与迁移实战指南

简介：MySQL 8.4.6 LTS 社区版 Windows 安装包（mysql-8.4.6.zip）面向需要稳定、长期支持数据库环境的开发者和数据库管理员，特别适合在 Windows 平台快速部署、学习源码或作为生产环境备选方案。该版本为开源社区维护的长支持版，兼顾功能完整性与持续更新，可满足教学实验、个人项目及部分业务场景对数据可靠性和安全性的要求。包内共有 2000 个文件，以 C/C++ 头文件（.h、.c）为主，辅以 Java、Python、Shell 等脚本、Markdown 文档及 XML 配置资料，便于从源码、工具和文档三个层面理解 MySQL 的构成与二次开发方向；压缩包整体约 521MB，ZIP 格式可免安装直接解压使用。目前已有 427 人下载学习。借助包内材料，读者可获得完整的 MySQL 8.4.6 源码目录、核心模块实现、扩展接口示例及配套说明文档，目录按模块组织便于定位关键代码，既可直接用于本地部署与测试，也可作为阅读源码、分析存储引擎和优化查询性能的参考素材。

1. MySQL 8.4.6 LTS：先拆掉 zip 包的使用价值

Windows 上安装 MySQL 不难，难的是给每套环境重复劳动。MySQL 8.4.6 LTS 是 8.4 系列中的补丁版本，官方定位为长期支持版；而 mysql-8.4.6.zip 这类 zip 包则把安装过程压缩成三件事：解压、初始化 data 目录、注册服务。对开发者和运维来说，zip 包比 MSI 适合多实例管理和自动化部署。

很多团队用 zip 包维护两套以上的实例：同一个解压目录复制一份，改改 my.ini 和服务名就是一套新环境。这套流程适合开发调试、性能压测和临时复现问题。后面步骤按 8.4.6 的实际目录结构来写，照做能跑通。

2. 8.4 LTS 的选型逻辑和版本边界：为什么能当生产主力

2.1 选型逻辑：把 LTS 版本周期和升级路径说清楚

MySQL 8.0 走到 8.0.36 之后，Oracle 改变了版本策略，把版本分为 LTS 与 Innovation 两类。8.4 是第一个与 8.0 并列的 LTS 版本，8.1、8.2、8.3 这些只是短周期的创新版本，从发布到停止补丁，往往只有半年到一年的支持窗口。生产库盯着 8.4 系列就对了，不用像追 8.1 那样为了新功能逼自己每半年升级一次。

还要关注升级路径。从 8.0 升到 8.4，不能直接拿 data 目录做原地替换。官方能够走通的安全路径是逻辑导出导入，或者按官方升级工具流程操作。实际操作时，我会在 8.0 实例上先查一遍业务库里有没有官方声明弃用的语法，再用 mysqldump 把业务库导出，在 8.4 实例上重新导入。这个过程会暴露很多现实边界问题，比如视图定义里的 DEFINER 用户不存在、触发器里有旧版本才支持的写法。跑完一遍数据校验，比对着官方升级文档推算更让人放心。

2.2 8.4 默认行为变化：认证插件、字符集和系统变量

装上 8.4 后第一个坑在认证插件。8.0 时代默认缓存 sha2 密码，旧插件 mysql_native_password 还能用于兼容；到了 8.4，官方直接禁用了这个旧插件。新建用户默认使用 caching_sha2_password，如果应用侧 JDBC 驱动、PHP mysqli、老版本客户端不认识这个插件，连接就会报 authentication plugin 相关错误，运气不好还是一串六进制错误码，连排查方向都难找。

字符集也一样。8.4 继续把 utf8mb4 作为默认数据库字符集，排序规则默认是 utf8mb4_0900_ai_ci，这与 8.0 的默认值一致。迁移的老库如果建表时显式写着 utf8mb4_general_ci，导入 8.4 后不会自动改，但新建表会走新排序规则。同一个库里的表排序规则一旦混用，关联查询时索引可能失效，WHERE 条件对大小写的判断也会出现差异。

系统变量方面，8.4 清理了一批旧参数。启动时看到 Unknown variable 提示，基本就是 my.ini 里写了 8.4 已移除的配置项。老项目迁移时最好先把配置梳理一遍，把官方声明作废的变量删掉，否则数据库启动失败，或者在启动日志里留下一堆无关紧要的警告。

2.3 zip 包和安装程序（MSI）的差异：什么时候不用纠结

MSI 安装程序会引导创建服务、初始化 data 目录、生成随机密码，失败时还会弹窗提示，对新手友好。但它的问题是过程不透明：注册表、服务名、目录路径和安装时做的选择强绑定，想批量复制一套环境得重新点一遍向导。

zip 包绕开了这些：解压后没有注册表依赖，mysqld.exe 可以直接前台运行，也可以自己决定注册成什么服务。用 zip 做多实例有明显优势：同一个二进制目录复制出多份，改 datadir、port、socket 和服务名，互相隔离，重启互不影响。生产环境如果是通过镜像批量交付，部署时用 zip 包配合脚本铺目录和 my.ini，效果比图形界面点安装更可持续。

如果你只是单机建一个开发库，不关心服务名和目录细节，MSI 省事；如果是要维护多套实例、做自动化、做基准测试，zip 包是更合理的底座。

3. 从 zip 解压到 Windows 服务：MySQL 8.4.6 标准安装流程

3.1 解压与目录规划：路径问题是第一道坑

下载回来的 mysql-8.4.6-winx64.zip 是标准的二进制目录压缩包，用 7-Zip 或 WinRAR 解压即可。两个注意事项：解压路径不要带中文和空格，带空格会让后续服务注册和命令行参数解析出幺蛾子；不要直接双击 zip 进入浏览，要把整个目录完整解压到目标盘符。

# 以管理员身份打开 PowerShell，把 zip 包解压到 D 盘根目录 $base = "D:\mysql" Expand-Archive -Path "D:\downloads\mysql-8.4.6-winx64.zip" -DestinationPath $base -Force

Expand-Archive 是 PowerShell 内建命令，Force 参数在目录已存在时覆盖同名文件，避免重复解压时遇到已存在提示。解压后的目录建议改短一点，比如 D:\mysql\mysql-8.4.6，后面所有命令和 my.ini 都要引用它，路径越短越不容易写错。

解压完成后确认目录结构，至少应该看到 bin、lib、share、docs 这几个子目录。其中 bin 是 mysqld.exe 和 mysql.exe 所在位置；share 存放错误消息和字符集定义；docs 里有官方 HTML 文档，排错时搜关键词很顺手。

3.2 配置 my.ini：最小可用配置与三个必调参数

zip 包默认不带 my.ini，服务器全靠内置默认值跑，但数据目录和端口往往不符合交付预期。在解压目录下新建 my.ini，这是 mysqld 启动时的配置依据。

[mysqld] basedir=D:/mysql/mysql-8.4.6 datadir=D:/mysql/mysql-8.4.6/data port=3306 character_set_server=utf8mb4 collation_server=utf8mb4_0900_ai_ci default_authentication_plugin=caching_sha2_password mysqlx=0

第一行 [mysqld] 表示这部分配置由服务器进程读取。basedir 和 datadir 必须写绝对路径，建议盘符后跟正斜杠，反斜杠在部分上下文里会被当成转义符处理。三个必调参数是 port、datadir、character_set_server；port 不写可能被默认 3306 绑架，datadir 不写会落在用户目录下，字符集不写可能导致建表时 charset 不统一。

default_authentication_plugin 显式写 caching_sha2_password，和默认行为一致，写上是让后来排查的人一眼看清意图。mysqlx=0 关闭 X 协议端口 33060，这台实例只提供普通 SQL 服务，不需要额外监听端口。innodb_buffer_pool_size 这里先不写，开发机用默认值 128M 起步很安全，等压测完再按内存调。

3.3 初始化 data 目录：--initialize 还是 --initialize-insecure

第一次启动前必须初始化 data 目录，否则 mysqld 一启动就退出，错误日志提示 data directory not found。初始化动作由 mysqld 自己执行，它会创建 mysql 库、系统表和必要的元数据文件。

D:\mysql\mysql-8.4.6\bin\mysqld.exe --defaults-file=D:/mysql/mysql-8.4.6/my.ini --initialize-insecure

常见做法是 --initialize-insecure，不生成随机密码，root 用户初始为空密码，适合刚装完要继续做自动化授权的场景。在意安全就用 --initialize，控制台会输出一段临时随机密码，第一次登录必须改。两种模式都会创建 data 目录并写入系统库，差别只在 root 初始密码的生成方式。

命令执行时间通常在几十秒内，窗口输出几行日志是正常的。执行完检查 data 目录下是否出现 mysql.ibd 和 ibdata1，看到这些文件基本可以放行。初始化只会做一次，重复执行不会重置已有数据目录。

提示：--initialize 和 --initialize-insecure 都要求在 data 目录不存在或为空时执行。如果目标目录已经有文件，mysqld 会直接拒绝初始化。

3.4 注册成 Windows 服务并启动

MySQL 自带的 mysqld.exe 支持把自身注册成 Windows 服务。开发环境可以每次前台启动验证，但服务化才是长久之计，数据库随系统自动拉起，不依赖人工开窗口。

D:\mysql\mysql-8.4.6\bin\mysqld.exe --install MySQL84 --defaults-file="D:/mysql/mysql-8.4.6/my.ini" net start MySQL84

mysqld --install 后面的 MySQL84 是自定义服务名。--defaults-file 必须写在同一命令行里，否则服务注册成功但启动时找不到配置文件，服务会陷入启动即退出的循环。注册成功后再执行 net start，看到服务名后跟“已启动”字样才算完成。

反安装同样简单：先 net stop MySQL84，再 mysqld --remove MySQL84，最后删掉 data 目录，整个环境就干净移除了。这也是 zip 包相对 MSI 的直观优势，卸载不需要碰注册表。

3.5 用客户端验证登录和基本状态

服务起来后第一件事就是验证登录，但 Windows 下 mysql 客户端默认连接方式有点隐蔽，容易踩 shared memory 和命名管道的坑。显式指定 TCP 连接最直接。

D:\mysql\mysql-8.4.6\bin\mysql.exe -uroot -p --protocol=TCP -h127.0.0.1 -P3306

--protocol=TCP 让客户端走 TCP 而不是本机默认的管道；-h 和 -P 指定回环地址与端口。登录成功后执行 SELECT VERSION() 确认版本号是 8.4.6，再执行 SHOW VARIABLES LIKE 'character_set_server' 核对字符集配置。第一次登录顺手把 root 空密码改掉，虽然内网开发机风险有限，但空密码的坏习惯总有一天会反噬。

4. 老项目迁到 8.4.6：数据、账号和 SQL 兼容性

4.1 迁移方式：mysqldump 逻辑导出的三个参数

老项目从 8.0 迁到 8.4，最可靠的方式是逻辑备份加导入。mysqldump 导出的 SQL 文件可以跨小版本迁移，导入时 MySQL 会重新解析建表语句、重建统计信息。以下命令在源 8.0 实例上执行：

D:\mysql\mysql-8.4.6\bin\mysqldump.exe -uroot -p --single-transaction --set-gtid-purged=OFF --default-character-set=utf8mb4 --databases mydb > mydb_84.sql

--single-transaction 对 InnoDB 表做一致性快照，导出过程中不锁业务表；--set-gtid-purged=OFF 很关键，源实例开启 GTID 时导出文件默认会写 SET @@GLOBAL.GTID_PURGED 语句，导入到 8.4 新实例上会因 GTID 状态不一致直接报错；--default-character-set=utf8mb4 控制客户端连接和导出文本的字符集，底层表结构真正用什么字符集还是看建表语句。

导入侧命令对应执行一把：

D:\mysql\mysql-8.4.6\bin\mysql.exe -uroot -p -h127.0.0.1 --default-character-set=utf8mb4 mydb < mydb_84.sql

导入完成后一定要做三件事：核对表数量、抽查大表行数、跑一遍业务侧常用查询。逻辑迁移慢一点，但每一步都能看到过程和结果，出问题能定位到具体 SQL。

物理迁移则是直接拷贝 data 目录。跨版本不推荐这样做，8.0 到 8.4 的数据字典格式有变化，直接替换 data 目录大概率启动失败，只有同版本同平台才值得考虑。

4.2 caching_sha2_password 排查：驱动、连接串和账号重建

8.4 禁用了 mysql_native_password，最明显的副作用在应用侧连接。旧版 MySQL Connector/J 5.x 不认识 caching_sha2_password，会直接抛 Unable to load authentication plugin；PHP 的 mysqli 扩展低于 7.4 也可能因为拿不到服务端公钥而卡住。

JDBC 连接串常见写法：

String url = "jdbc:mysql://127.0.0.1:3306/mydb?useSSL=false&allowPublicKeyRetrieval=true&characterEncoding=utf8";

allowPublicKeyRetrieval=true 允许客户端向服务器请求 RSA 公钥完成密码加密传输，对没有配 SSL 的连接是必要的；useSSL=false 表示无加密传输，如果服务端开了强制 SSL，要改成 true 并配置证书。迁移旧账号时不要试图重新启用被禁用的插件，直接在 8.4 上重建用户更干净。

4.3 字符集与排序规则：utf8mb4 的遗留坑

迁移后中文查询异常，十有八九是排序规则不一致。8.0 时代大量旧表用 utf8mb4_general_ci，8.4 的默认排序规则是 utf8mb4_0900_ai_ci。两者对大小写、重音和部分特殊字符的处理逻辑不同，做模糊搜索或索引匹配时结果可能不一致。

ALTER DATABASE mydb CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci; ALTER TABLE mydb.t_news CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;

CONVERT TO CHARACTER SET 会把表内所有字符列转换为目标字符集，并重建统计信息。大表执行会长时间锁表，必须放在业务低峰期。迁移完成后用 SET NAMES utf8mb4 重跑应用查询，逐条比较新旧库的返回结果，排序规则差异最容易在这里暴露。

4.4 被移除的 SQL 语法：迁移时的陷阱

8.4 清理了一批长期废弃的语法，导入导出时最容易踩到的有：GROUP BY 后直接写 ASC/DESC，这在 8.0 已经废弃；PASSWORD() 函数早已移出正式支持；部分 optimizer_switch 参数名被改写。迁移导入报 syntax error 时，先把 SQL 语句在 8.4 上单条执行，锁定具体报错字符位置。

sql_mode 的严格程度也会影响导入。如果旧库早期建表时用了宽松模式，字段默认值不合法还能写进去，导入到 8.4 开启 STRICT_TRANS_TABLES 就会失败。遇到这类问题，临时用 SET SESSION sql_mode='' 导入，再逐表修正数据，不要上来就改全局 sql_mode。

5. 安装 8.4.6 的常见问题与排查：现象、原因、解决

5.1 error 2002 连不上：socket 还是端口问题

现象：执行 mysql -uroot -p 后报 ERROR 2002 (HY000): Can't connect to local MySQL server through socket。

原因：这个报错在 Windows 上几乎每天都能看到。客户端默认尝试连接本地 socket 文件，但 MySQL 8.4 的 Windows 版并不监听 Unix socket，而是走 TCP 端口或命名管道。服务明明在运行，仍然报 2002，多半是客户端连接方式不对；其次是 3306 端口没起来或防火墙拦截虚拟机外部访问。

解决：先确认服务是否在运行，再看端口监听状态。

netstat -ano | findstr 3306

如果没有任何输出，说明 mysqld 没起来，去 data 目录下找 .err 日志看真正原因。如果端口在监听但客户端连不上，检查 Windows 防火墙是否放行 mysqld.exe。再用 mysql -uroot -p -h127.0.0.1 -P3306 --protocol=TCP 强制走 TCP，这一条能避开一大半连接层的坑。

5.2 初始化成功但服务无法启动：权限与目录归属

现象：mysqld --initialize 正常生成 data 目录，但 net start 后服务提示启动失败，错误日志里出现 Permission denied。

原因：Windows 服务进程默认以 SYSTEM 账户运行，解压目录如果放在用户目录或带 ACL 限制的路径下，SYSTEM 可能没有 data 目录的写入权限。最常见的位置是桌面、下载文件夹以及部分网盘同步目录。

解决：把整个 MySQL 目录移到 D:\mysql 这类盘符根目录，右键目录属性，在“安全”中添加 SYSTEM 的完全控制权限。移动后卸载并重装服务，因为旧服务注册表里还存着原路径。改完路径后还要同步修改 my.ini 的 basedir 和 datadir。

提示：注册服务前先把目录权限确认好。Windows 服务排错比 Linux 更让人头疼，服务管理器给的报错信息往往只是“已停止”，真正有用的内容全在 .err 日志里。

5.3 忘记 root 密码：skip-grant-tables 用法变化

现象：沿用 8.0 旧文档，用 skip-grant-tables 启动后执行 UPDATE mysql.user 改密码，在 8.4 里不生效或者操作被拒。

原因：8.4 强化了权限表的校验逻辑，skip-grant-tables 模式下不刷新权限直接 UPDATE，修改可能被回滚。另外 8.4 的 user 表包含多列认证信息，只改某个密码字段根本不够。

解决：先停止 MySQL 服务，再以前台方式启动临时实例。

mysqld --defaults-file=D:/mysql/mysql-8.4.6/my.ini --skip-grant-tables --console

另开一个终端连入后，必须先执行 FLUSH PRIVILEGES 让权限表进入可写状态，然后执行 ALTER USER：

FLUSH PRIVILEGES; ALTER USER 'root'@'localhost' IDENTIFIED BY 'newpass';

改完退出，关掉临时进程，重新启动正常服务。不要用 update 语句改 authentication_string，8.4 的认证信息结构不允许这样绕。

5.4 服务注册成功后自动停止：前台启动抓真实错误

现象：net start MySQL84 后，服务管理器状态停在“正在启动”，十几秒后变成“已停止”，但系统日志里没有明确的错误码。

原因：多半是 my.ini 里写了启动时无法满足的配置项。例如 basedir 路径写错、datadir 指向了已有文件的目录、或者配置里引用了 8.4 已删除的系统变量。Windows 服务管理器对 mysqld 的启动失败提示很模糊，不把真实错误翻译出来。

解决：绕开服务管理器，直接在前台跑 mysqld，让错误直接打到控制台。

D:\mysql\mysql-8.4.6\bin\mysqld.exe --defaults-file=D:/mysql/mysql-8.4.6/my.ini --console

前台启动的信息详细得多。看到 Unknown variable 说明 my.ini 里配置项已失效；看到 Can't open shared library 说明插件路径有问题；看到 Can't find messagefile 说明 share 目录位置不对。把前台报错逐条清掉，再回服务管理器启动就顺畅了。

5.5 数据目录直接覆盖：升级时的危险操作

现象：机器上跑着 8.0.36，直接把 mysql-8.4.6-winx64 解压覆盖到原目录，启动时新版本无法识别旧 data 目录，或者服务反复重启。

原因：MySQL 的 data 目录与二进制版本强耦合。8.0 到 8.4 虽然数据字典大方向兼容，但系统库表结构不同，直接替换二进制目录而没有走升级流程，数据字典会处于不一致状态，mysqld 会拒绝启动。

解决：zip 包覆盖前先备份整个 data 目录和 my.ini，然后不要原地启动，而是走逻辑导出导入。测试机上想试原地升级，必须按官方流程备份、替换、启动、执行升级工具，整个过程耗时较长，失败风险不低。生产环境我一律逻辑迁移，宁可多花时间导入导出，不赌原地升级的运气。

6. 安装后的验证和调参：mysqladmin ping 与 mysqlslap

6.1 用 mysqladmin 和 mysqlslap 做安装后体检

服务跑起来，先用最轻量的命令确认进程存活。

D:\mysql\mysql-8.4.6\bin\mysqladmin.exe -uroot -p -h127.0.0.1 ping

返回 mysqld is alive 就说明服务正常。接下来用 mysqlslap 做一轮简单并发读写，看配置是否明显不合理。

D:\mysql\mysql-8.4.6\bin\mysqlslap.exe -uroot -p --concurrency=10,20,50 --number-of-queries=1000 --create-schema=test --query="SELECT * FROM t_demo WHERE id=1"

concurrency=10,20,50 表示分别用 10、20、50 个并发跑三轮，观察不同并发下的单次查询耗时。mysqlslap 是 MySQL 自带工具，不需要额外安装，适合安装后快速体检。如果 50 并发时耗时从个位数毫秒跳到几十毫秒，说明实例能力或配置有瓶颈，此时再考虑调 buffer pool 和连接数。

6.2 连接池和 innodb_buffer_pool_size：默认值先跑一周再说

调参的第一原则是看数据再动手，而不是装完就改。innodb_buffer_pool_size 是 InnoDB 的内存池，开发机 512M 足够，生产环境按物理内存的 60% 到 70% 拍一版，然后观察命中率和磁盘 IO 再微调。连接数不用贪多，默认 151 个连接对绝大多数系统够用，应用侧连接池大小反而比数据库 max_connections 更影响响应时间。

我自己的习惯是：新环境一律先用 zip 包装标准基线配置，跑一周，看慢查询日志、连接数和内存监控，有实际数据支撑再动缓冲池和连接数的配置。8.4 的很多默认值是官方依据线上场景调过的结果，没有明确的监控数据就乱调参数，是在给自己埋坑。这套 zip 包部署的流程我重复了很多次，每次都能在五分钟内交付一套独立实例，希望帮到你。

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