给 Windows 10 上跑了好几年的 MySQL 5.5 做升级说难不难说简单也真不简单。我刚帮一台老机器把 MySQL 5.5 完整升级到 5.7整个过程踩了字符集、SQL 模式、用户权限迁移、服务安装好几个坑最后整理出了一套可以直接照着做的流程。这篇指南就是给同样要在 Windows 10 下做 MySQL 5.5 到 5.7 升级的运维、开发和个人站长看的核心思路是先备份、再干净安装新版、最后迁移数据并验证强调稳而不是快。1. 升级前的体检先看清你手里的 MySQL 5.5 是什么状态1.1 确认版本、位数与配置文件位置升级第一步不是下载新版本而是先把自己这台 5.5 的底细摸清楚。我一般会登录数据库执行这几条SELECT VERSION(), version_comment; SHOW VARIABLES LIKE port; SHOW VARIABLES LIKE datadir;版本号、端口、数据目录这三个信息是必看的。数据目录决定了你备份时要覆盖哪些文件端口决定了后面新旧服务怎么并行跑。配置文件位置也要记录。Windows 下 5.5 的 my.ini 可能在安装目录比如C:\Program Files\MySQL\MySQL Server 5.5\里也可能在C:\ProgramData\MySQL\MySQL Server 5.5\下。最简单的确定办法是打开服务管理器WinR 输入services.msc找到 MySQL 服务查看可执行文件的路径里面通常会带--defaults-file...参数那个路径就是它启动时真正读取的配置文件。还有一个很容易忽略的点确认系统是 64 位还是 32 位。如果机器是 64 位系统旧库也跑得动那新装 5.7 直接用 64 位版本如果系统本身是 32 位后面选版本的时候就得特别小心因为新版对旧系统支持越来越差。检查方法很简单此电脑右键属性看一眼。1.2 摸清业务特征引擎、字符集和对象规模升级前最好花十分钟统计一下库里都有什么因为 5.5 到 5.7 不只是版本号变了默认行为和部分机制也不同。我建议执行这几类查询SHOW ENGINES; SELECT character_set_server, collation_server; SHOW VARIABLES LIKE sql_mode;第一条看存储引擎。5.5 时代很多人还在用 MyISAM升级到 5.7 之后 InnoDB 已经是绝对主流MyISAM 虽然还能用但功能上已经被边缘化。如果你手里有大表还是 MyISAM建议升级后抽时间转成 InnoDB尤其是要长时间跑的业务表。第二条看服务器默认字符集。5.5 安装时很多环境默认是 latin1但业务表可能单独设置了 utf8这两者混在一起最容易在迁移后出现乱码。先记录原始状态后面迁移步骤里我会专门说怎么处理。再统计一下对象规模SELECT table_schema, COUNT(*) AS table_count FROM information_schema.tables WHERE table_schema NOT IN (information_schema, performance_schema, mysql) GROUP BY table_schema; SELECT table_schema, ROUND(SUM(data_length index_length) / 1024 / 1024, 2) AS size_mb FROM information_schema.tables GROUP BY table_schema;这两个查询能让你知道一共多少个库、每个库多大。如果总数据量只有几百 MB导出导入非常快如果有几十 GB那就得认真评估停机窗口甚至要考虑分库导出的方案。1.3 升级路线选择为什么这次选择 5.7 而不是直接上 8.0这是我在做方案时最先想清楚的问题。MySQL 5.5 到 5.7 已经跨了两个大版本为什么要停在 5.7 而不是一步到位上 8.0我的理由很实际对老项目来说平滑过渡比追求最新版本重要。5.7 在认证插件、默认字符集、SQL 模式上和 5.5 已有明显差异但这些差异还在可以控制的范围内而 8.0 的默认认证插件caching_sha2_password、默认字符集、数据字典重构会带来更多连锁反应老旧客户端和代码连接时很容易出现莫名其妙的问题。如果业务代码已经停更多年先升到 5.7 把环境稳定下来之后再规划 8.0 反而更稳妥。当然如果这是全新的项目没有老数据包袱那直接上 8.0 完全没问题。但今天这篇讲的是 5.5 升级目标版本就定为 5.7。2. 备份与迁移方案放弃复制 data 目录走导出导入2.1 两条升级路线的基本逻辑网上关于升级 MySQL 的说法很多但落到 Windows 10 上基本就两条路in-place 升级和逻辑迁移。in-place 升级的做法是停掉旧服务把新版本的安装目录指到旧 data 目录上然后启动新版本并运行 mysql_upgrade 工具。这套思路看起来最快但 5.5 跨到 5.7 时风险不小。旧版本的 mysql 系统库表结构和新版本不完全一致mysql_upgrade 在处理某些系统表时可能报错而且一旦升级过程中出了问题回滚很麻烦因为你手里的 data 目录已经被新版本动过了。逻辑迁移的做法是用 mysqldump 把数据导出成 SQL 文件然后在全新的 5.7 实例里重新导入。虽然导出导入耗时明显更久但整个过程可控、可回滚、可验证。万一导入出错旧库还完好无损随时可以重来。我这次选择的是逻辑迁移。理由很简单这台机器上的数据虽然不是特别多但属于业务在用的生产数据稳定性优先。对比项in-place 升级逻辑迁移导出导入操作速度快几乎只是停启服务慢取决于数据量回滚难度难data 目录可能被改容易旧库原样保留兼容性风险高系统表结构跨版本冲突低全新系统表无冲突数据对象覆盖依赖 mysql_upgrade依赖导出参数完整性适合场景小版本升级、测试环境跨大版本、生产环境2.2 mysqldump 导出命令与 PowerShell 重定向的编码大坑备份命令我建议在 cmd 里执行并且强烈建议不要一键导出所有数据库。--all-databases会带上 mysql 系统库但 5.5 的 mysql 库表结构和 5.7 差异明显直接导入必踩坑这个我后面专门有章节说明。更好的做法是分库导出业务数据。我用的命令长这样cd C:\Program Files\MySQL\MySQL Server 5.5\bin mysqldump -uroot -p \ --single-transaction \ --routines \ --triggers \ --events \ --default-character-setutf8 \ --databases olddb1 olddb2 \ --result-fileD:/backup/mysql55_olddb_20240101.sql几个参数说明一下--single-transaction对 InnoDB 表做一致性快照导出过程中不锁表。如果库里还有大量 MyISAM 表这个参数对它们无效MyISAM 表导出时仍可能锁表所以停机窗口要留够。--routines导出存储过程和函数这个特别容易漏。--triggers导出触发器。--events导出事件调度器任务。--default-character-setutf8指定客户端连接字符集。如果旧库表本身是 latin1 且里面存了中文这个参数的具体取值要看情况我放到第 4 章专门说。--result-file直接让 mysqldump 写文件而不是用 shell 的重定向。最后这个--result-file是我踩过的真实大坑。在 PowerShell 里执行mysqldump ... backup.sqlPowerShell 5.1 默认会把输出写成 UTF-16 编码文件开头带 BOMmysql 客户端导入时根本不认报各种乱码或语法错误。在 cmd 里用重定向也有风险因为我遇到过管道把结果集按当前代码页转换的情况。用--result-file参数可以让 mysqldump 自己写文件完全绕开 shell 重定向的编码问题。还有一个原则密码不要直接写在命令行里。让命令提示输入即可否则历史记录里全是明文密码太不安全。2.3 导出文件的落地检查导完之后别急着开始装新版先确认备份文件靠不靠谱。我最常做三个检查第一个看文件末尾是否包含完成标志findstr Dump completed D:\backup\mysql55_olddb_20240101.sql如果文件不完整通常末尾不会有这行字。第二个看文件大概多大、INSERT 语句数量是否合理dir D:\backup\mysql55_olddb_20240101.sql find /c INSERT INTO D:\backup\mysql55_olddb_20240101.sql第三个也是最稳的一个临时搭一个测试库把备份文件导入一次。不用等全部验证完只要能导进去、能跑起来、能查到几条典型数据就说明备份文件本身是健康的。我见过有人备份文件看着很大结果导到一半发现某个存储过程没带上就是因为缺了--routines。3. 新版本部署Windows 10 下 MySQL 5.7 的干净安装3.1 下载版本与解压布局MySQL 5.7 的 Windows 版本下载页面对应的是 ZIP Archive 压缩包不是 MSI 安装包。我的经验是优先用 ZIP 解压版本理由很简单安装目录、数据目录、服务名全部可以自己控制不会像安装包那样默认塞到C:\Program Files里也不容易被 Windows 权限问题缠上。下载时注意选择 5.7 系列里最新的小版本比如 5.7.44。有人问为什么官方序列里 5.7 后面从 43 跳到 44 甚至更晚其实就是安全补丁的版本号递增选最新的带安全修复的小版本就对了。注意别下成 8.0 的安装包这一步手滑了后面全乱。解压目录我建议用一个简单干净、不带空格和中文的路径比如D:\mysql57。解压后 bin 目录下有 mysqld.exe 和 mysql.exe先不着急加环境变量。因为这台机器上还装着 5.5如果 PATH 里已经有旧版 MySQL 的 bin 路径你新装完一敲 mysql 命令很可能还是旧版的排查起来很头大。升级期间所有命令我都用绝对路径D:\mysql57\bin\xxx.exe来执行等旧的彻底退役了再调整 PATH 不迟。3.2 my.ini 配置要点路径、字符集与端口5.7 在启动时如果没有显式指定配置文件会去默认目录找。为了让它精确使用我们的配置我强烈建议建一个明确的D:\mysql57\my.ini内容参考下面这份[mysqld] basedirD:/mysql57 datadirD:/mysql57/data port3306 server-id1 character-set-serverutf8mb4 collation-serverutf8mb4_general_ci explicit_defaults_for_timestampON max_connections500 innodb_buffer_pool_size512M sql_modeNO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES [client] port3306 default-character-setutf8mb4几个点特别强调一下basedir和datadir必须写绝对路径斜杠正反都行但不要用带空格的路径。datadir这个目录在初始化前可以不存在mysqld --initialize会自动创建但它创建的前提是父目录有写权限所以我特意把整个 MySQL 放在 D 盘根目录下。character-set-serverutf8mb4是升级重点。5.7 对 utf8mb4 的支持已经成熟业务里如果有 emoji 字符只有 utf8mb4 能存得下。explicit_defaults_for_timestampON是 5.7 的默认行为。旧代码如果依赖 TIMESTAMP 自动初始化为当前时间建表语句里得显式写DEFAULT CURRENT_TIMESTAMP这个升级后会注意到。sql_mode这里我暂时写成默认的严格模式。但如果为了导入老数据要临时放宽可以在会话级别改不需要改配置文件。3.3 初始化、服务安装与旧服务并行策略目录准备好之后打开一个管理员权限的 cmd依次执行D:\mysql57\bin\mysqld --initialize-insecure --console--initialize-insecure会生成一个 root 密码为空的实例这对于本地迁移场景非常方便。如果你用--initialize会生成一串随机密码藏在 error log 里第一次登录要翻日志找非常麻烦。生产环境我反而不介意麻烦但迁移场景一切以方便为优先。初始化完成后再安装服务D:\mysql57\bin\mysqld --install MySQL57 --defaults-fileD:\mysql57\my.ini服务名取MySQL57不要叫MySQL因为旧服务已经占用了这个名字。安装完启动net start MySQL57启动后用绝对路径登录验证D:\mysql57\bin\mysql -uroot如果直接进入 mysql 提示符说明新实例已经正常运行。此时旧服务如果还开着端口 3306 会被占用新服务启动会失败。我习惯的并行策略是先停掉旧服务net stop MySQL让 3306 空出来或者把新旧服务分别放到 3306 和 3307 两个端口上并行跑。等数据迁移验证完再彻底处理旧服务。4. 数据迁移与跨版本排雷带过来的数据为什么会被 5.7 拒绝4.1 字符集latin1 中文的乱码陷阱这是整个升级过程中最容易出事的一环。5.5 时代很多库表的默认字符集是 latin1但业务写入时可能是 GBK 或者被程序强行以 utf8 理解。这种混装状态在旧版本里跑得好好的一导出导入就会暴露问题。迁移前先看每个表的字符集分布SELECT table_schema, table_collation, COUNT(*) AS cnt FROM information_schema.tables WHERE table_schema NOT IN (information_schema, performance_schema, mysql) GROUP BY table_schema, table_collation;如果所有表都是 utf8 或 utf8mb4那恭喜你迁移时会省心很多。如果存在 latin1 表并且里面有中文不要急着直接导出导入。我的建议是先在旧库把字符集统一成 utf8 再做导出命令类似ALTER TABLE t1 CONVERT TO CHARACTER SET utf8;注意ALTER TABLE ... CONVERT TO CHARACTER SET会重写整张表大表很耗时要放在维护窗口里操作。如果不想动旧库可以在旧库里复制一张临时表转换测试确认导出文件里的中文能原样还原再正式迁移。导入时再用--default-character-setutf8mb4指定客户端字符集。这样整个链路从导出、文件内容到导入客户端都对齐就不会乱码。4.2 sql_mode 从宽松到严格日期与截断问题5.5 的默认sql_mode是空字符串意味着数据写入非常宽松日期可以写0000-00-00字符串超出长度会被静默截断GROUP BY 也不强制非聚合列必须出现在分组里。5.7 默认的sql_mode是类似这样的严格组合ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION后果很直接表里有0000-00-00的日期导入时直接报错ERROR 1292 (22007): Incorrect date value: 0000-00-00。超长字符串不再警告截断而是直接报错写不进去。老代码里SELECT name, COUNT(*) FROM t GROUP BY age这种查询以前能跑现在报ERROR 1055。我迁移时遇到的就是第一种情况导入到一半报日期错误。处理方法是在导入连接里先放宽 sql_modeSET SESSION sql_modeNO_ENGINE_SUBSTITUTION;还要配合关闭外键检查SET FOREIGN_KEY_CHECKS0; SET UNIQUE_CHECKS0;导入完成后再对数据做修正比如把非法的零日期改成1970-01-01UPDATE t1 SET create_time 1970-01-01 00:00:00 WHERE create_time 0000-00-00 00:00:00;修正完毕再将 sql_mode 恢复成严格模式。如果业务代码完全无法适配严格模式那也可以让实例长期保持宽松模式代价是数据质量下降这个权衡要业务方拍板。4.3 用户权限迁移不要直接导入 mysql 系统库这是我踩得最重的一个坑也是很多人升级时没意识到的点。有些教程让你mysqldump --all-databases一把梭然后新库直接导入看起来省事实际上 mysql 系统库的表结构在两个大版本之间变过太多导入时大概率报ERROR 1054之类而且用户表里Password列在 5.7 已经改成了authentication_string盲导入只会越导越乱。正确的姿势是业务数据统一按库导出导入用户账号单独处理。先在旧库上查看需要迁移的账号和对应权限SELECT User, Host FROM mysql.user WHERE User NOT IN (root);对每个账号执行SHOW GRANTS FOR app%;把输出的授权语句复制下来到新库执行。注意5.5 输出的授权语句里可能带着IDENTIFIED BY PASSWORD *hash这种语法在 5.7 里会报错需要改成CREATE USER app% IDENTIFIED WITH mysql_native_password AS *hash; GRANT SELECT, INSERT, UPDATE, DELETE ON olddb1.* TO app%;先建用户、再授权这个顺序不能乱。因为业务库里的存储过程、触发器、视图都带有定义者DEFINER如果被引用账号不存在导入时会出现ERROR 1449: The user specified as a definer (...) does not exist。把相关账号提前建好这类问题直接消失。4.4 导入操作与验证清单一切就绪后开始导入。先用 root 建库再导入数据CREATE DATABASE olddb1 CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;命令行导入D:\mysql57\bin\mysql -uroot -p --default-character-setutf8mb4 olddb1 D:\backup\mysql55_olddb_20240101.sql导入过程如果报错先看是哪种类型。日期类问题按 4.2 放宽 sql_mode外键顺序问题用SET FOREIGN_KEY_CHECKS0权限问题查 DEFINER。导入完成后按这份清单逐项验证表数量对比旧库information_schema.tables的表数量和新库完全一致。行数抽查挑核心大表两边分别SELECT COUNT(*)对比。存储过程和触发器执行SHOW PROCEDURE STATUS WHERE Dbolddb1;和SHOW TRIGGERS;确认对象都还在。事件调度器执行SHOW EVENTS;确认迁移后事件任务没丢。5.7 默认 event_scheduler 是开启的如果没开用SET GLOBAL event_scheduler ON;。自增主键查看关键表的SHOW TABLE STATUS LIKE orders;确认Auto_increment值没有异常回退。中文抽样查询几条含中文的记录肉眼确认没有乱码。验证不是一次性的我建议导入第二天再让业务方抽查一次真实查询结果因为有些逻辑错误要跑起来才能发现。5. 升级后的运行观测与应急处理5.1 实例健康速查SQL 与日志双通道升级完成不代表万事大吉我习惯在新实例上线后先跑一轮基础检查SELECT VERSION(), port, datadir; SHOW VARIABLES LIKE character_set_server; SELECT sql_mode; SHOW GLOBAL STATUS LIKE Threads_connected; SHOW GLOBAL STATUS LIKE Slow_queries;连接数、慢查询数、字符集和 sql_mode 是最需要关注的四项。慢查询在升级后短时间内偏高是正常的因为 InnoDB 缓冲池是冷的查询要走磁盘跑一阵子会降下来。日志也得盯。执行SHOW VARIABLES LIKE log_error;5.7 默认会把错误日志写到 data 目录下的.err文件里。Windows 下启动失败时第一现场基本都在这个文件里比事件查看器的信息有用得多。5.2 5.7 带来的行为变化初始化方式、时间戳、性能库升级后你还会发现一些和 5.5 明显不同的行为。初始化方式变了。5.5 时代建库是通过mysql_install_db脚本5.7 变成了mysqld --initialize或--initialize-insecure。这个变化是向前不兼容的以后在 Windows 上再装新实例得习惯新命令。时间戳行为变了。5.7 默认explicit_defaults_for_timestampONTIMESTAMP 列不会再自动用当前时间填充。老代码里如果写过依赖隐式默认值的建表语句查询或插入时会出现诡异的数据异常解决办法就是显式加DEFAULT CURRENT_TIMESTAMP。性能监控能力变强了。5.7 默认开启了 performance_schema还附带 sys 库。比如查锁等待可以一行搞定SELECT * FROM sys.innodb_lock_waits;这在 5.5 时代是想都不敢想的便利。如果在升级后遇到锁等待排查直接看这个视图比翻SHOW ENGINE INNODB STATUS直观太多。5.3 常见故障速查起不来、登不进、导入报错最后整理一个我这次实操中反复用到的故障速查表都是 Windows 10 MySQL 5.7 迁移时最常撞上的问题。现象常见原因处置net start MySQL57报 1067 错误datadir 路径错误、目录无权限、端口被占前台执行mysqld --defaults-fileD:\mysql57\my.ini --console看直接输出的错误netstat -ano | findstr :3306查端口mysql -uroot无法登录root 密码不是空、随机密码没找到、skip-grant-tables残留检查.err日志找初始密码或停服务后用--skip-grant-tables启动并重置密码导入报ERROR 1292严格模式下零日期被拒导入连接先SET SESSION sql_mode导入后修复数据再恢复导入报ERROR 1449存储过程的 DEFINER 用户不存在先把对应账号CREATE USER建好再重新导入业务查询报ERROR 1055ONLY_FULL_GROUP_BY导致老 SQL 挂掉改写 SQL 让非聚合列全部出现在 GROUP BY实在无法改再考虑放宽模式网页或客户端显示乱码连接串 charset、库表字符集链路不一致连接串统一加charsetutf8mb4表统一CONVERT TO CHARACTER SET utf8mb4我个人在整个升级过程中最深的体会是跨版本升级不是新版本替换旧版本而是数据在两个不同行为体系之间的一次完整搬迁。导出的速度不重要导入的顺利也不值得高兴得太早真正决定成败的是验证阶段有没有把字符集、sql_mode、用户权限和对象完整性逐项核对过。另外升级成功后别急着删除旧的 data 目录和服务至少保留三个月等业务完全稳定后再清理。最后再分享一个我自己的习惯每次迁移都会在测试机先完整演练一遍把业务查询脚本提前准备好迁移当天只复制操作不临时想方案这套流程走下来升级这事基本就不会翻车。